- Hard TTL; the maximum time a value will be used from the cache.
- Soft TLL; the time after which the cache value should be updated
from the server.
So as not to unnecessarily fetch the same value multiple times, when
the soft TTL has been reached, the value will be updated for the first
client, while all other clients will use the stale value until it has
become updated.
With different soft and hard TTLs there is a definite upper bound for
how old a value can be used.
In order for the LRU storage to correctly track the state in the
real storage, we always need to know stale-state of a returned
(or not returned) value.
The return type is now not an a pure enumeration, but a 16-bit
enumeration plus a 16-bit bitmask that can be used for conveying
more information.
- CamelCase for all C++ class and template names
- snake_case for all variables, including member variables and
member functions
- Static member functions start with a capital letter
- Member variables prefixed with m_
- Static member variables prefixed with s_
- Null terminated character string variables prefixed with z
- Pointers prefixed with p
- Smart-pointers prefixed with s
- Where a z, p, or s prefix is present, the following letter is
capitalized, i.e., pEntry and not pentry.
Now all storage configuration values are provided in a single object.
That way it'll be easier to provide more if necessary and also makes
it straightforward to fetch the configuration, which makes it possible,
for instance, to adapt tests according to the way the storage has been
configured.
16MBytes packets are now handled in MULTI result sets as well.
MAXROWS_DISCARDING_RESPONSE state has been removed.
Two new flags control large packets and result discarding
gwbuf_clone cloned only the first buffer of a chain of buffers,
which never can be the desired outcome, while gwbuf_clone_all
cloned all buffers.
Now, gwbuf_clone behaves the way gwbuf_clone_all used to behave
and gwbuf_clone_all has been removed.
The luafilter exposes two of the main functions provided by the query
classifier API; the type and operation classification.
The functions can be used by the Lua script with minimal overhead as the
current query being executed is stored only as a pointer. The functions
should only be called inside the `routeQuery` entry point of a Lua script.
Now that the cache key can be generated using the StorageFactory
there is no need for calling back into the derived class from Tester
to get hold of one. Instead the preparatory work is performed by
the abstract base classes, then the control is moved back to the
derived concrete class that decides what to actually do.
A Tester class that simplifies the creation of various cache tests.
It provides the basic mechanisms for reading statements from MySQL/
MariaDB test files, for converting statements into equivalent
cache items (key + statement) and for running various tasks in
separate threads for a specific amount of time.
RocksDB returns success when deleting a non-existing key. To deal
with that the book-keeping of LRUStorage is used and the real
underlying storage is used only if LRUStorage thinks a particular
key exists.
Now also rudimentary tests the LRU mechanism, which at the same
time makes the name a misnomer. These will be split into separate
programs to allow tests to be run individually.
With the addition of filter capabilities, the tee filter should work with
all sorts of routers that require at most the RCAP_TYPE_CONTIGUOUS_INPUT
capability.
Due to a recent discovery of the server's capability to process multiple
requests, the filter can safely send data from one service to another
without waiting for the earlier replies.
This also fixes a minor problem with the cloning of DCBs where the backend
DCBs could end up in the wrong thread's pool.
In order to be able to test the LRU mechanism properly you need
to be able to access the head and tail from the outside. The same
is regarding the size and items in the cache. In order to be able
to test that the guarantees are upheld, you need to be able to
access those values from the outside.
It would seem that the likelyhood of different threads accessing
the same items at the same time is greater if each thread continuosly
loops across all items from beginning to finish. That will also ensure
that head and tail surely are accessed. In addition, some function names
have been disambiguated.
If the underlying storage does not support max_count and/or max_size
and it accordinly is decorated with LRUStorage, then create the real
storage as single-threaded. Since LRUStorage will do locking it is of
no use to do locking in the real storage as well.
Here we create a number of threads and then randomly start getting
putting and deleting values. The intent is to test that the locking
behaviour of the storage modules is correctly implemented.
