The CacheQueueInterceptorPlugin offers the ability to store messages persistently on databases. In case a crash occurs, data will be recovered. Since it embeds a jdbc queue and a ram queue, it has the ability to cache entries on ram, improving this way the performance. On demand it is possible to inhibit swapping.
Here follows a graphical explanation about the caching mechanism.
The cache queue offers a mechanism for swapping. There are basically three different kind of threads which are playing a role in the queue: the put threads, the take/remove/peek threads and a third kind of thread which only acts in case the connection to the DB has been lost: the reconnection timeout thread.
The synchronization principles and the status diagram of the cache queue is described in the following picture.
<qos> <queue maxEntriesCache='1000' maxBytesCache='4000' maxEntries='10000' maxBytes='1000000000' onOverflow='deadMessage'/> </qos>
These parameters allow to configure a cache queue, the 'queueName' needs to be replaced by 'history', 'callback' or 'subject' to configure those specific queues or additionally by 'connection' on client side to configure the client side tail back queue.
Property | Default | Description | Hot | Impl |
---|---|---|---|---|
QueuePlugin[CACHE][1.0] | org.xmlBlaster.util.queue.cache.CacheQueueInterceptorPlugin | specifies the cache implementing class to be used | ||
queue/'queueName'/maxEntries | queue/history/maxEntries = 1000 | specifies the maximum number of entries allowed in the persistence portion of this queue | ||
queue/'queueName'/maxBytes | 10485760L | (10MB) specifies the maximum total size for the persistence portion allowed in this queue | ||
queue/'queueName'/maxEntriesCache | 1000 | specifies the maximum number of entries allowed in the RAM portion of this queue | ||
queue/'queueName'/maxBytesCache | 2097152 | (2MB) specifies the maximum total size for the RAM portion allowed in this queue | ||
queue/cache.storeSwapLevel | 70 % of the cacheMaxBytes in bytes | The level in bytes over which the cache queue starts swapping, i.e. it will start to take from the ram and put in jdbc storage. | ||
queue/cache.storeSwapBytes | 25 % of the cacheMaxBytes in bytes | The amount in bytes to swap each time data must be moved from ram to jdbc storage. | ||
queue/cache.reloadSwapLevel | 30 % of the cacheMaxBytes in bytes | The level in bytes under which which the cache queue starts reloading data from the persistence and puts it in the ram queue. | ||
queue/cache.reloadSwapBytes | 25 % of the cacheMaxBytes in bytes | The amount in bytes to swap each time data must be moved from jdbc to ram storage. | ||
queue/'queueName'/defaultPlugin | queue/callback/defaultPlugin = CACHE,1.0 | The default implementation to be used for queues, it defaults to the here described cache plugin. |
StoragePlugin[CACHE][1.0]=org.xmlBlaster.engine.msgstore.cache.PersistenceCachePlugin,persistentQueue=JDBC,transientQueue=RAM
Property | Default | Description | Hot | Impl |
---|---|---|---|---|
transientQueue | RAM,1.0 | The implementation to be used for the transient portion of the cache queue. | ||
persistentQueue | JDBC,1.0 | The implementation to be used for the persistent portion of the cache queue. |