|Topic||Within XmlBlaster there is a complete queue framework offering generic plugin based storage. The queues can be persistent or transient.|
Queues can (and are) used in different parts in xmlBlaster. On client side they are used to store the messages waiting to be delivered to xmlBlaster. This is commonly the case when the communication between client and server is temporarily down.
On the server side there are callback queues (also called update queues) to temporarily store messages waiting to be delivered, for example callbacks to client subscriptions or PtP messages, or to persistently store the messages in order to be able to recover after a server crash.
Another usage of queues within xmlBlaster is the storage of the history of messages, i.e. to store several publishes made on the same message-oid.
Queues are also used as swapping devices to free memory when memory consumption is high.
The different queue implementations used within xmlBlaster are plugins, so if you want some specific feature, or if you want to implement your own queue, this can be done.
Queue entries have priorities (from 0 to 9) and a guaranteed order of delivery within the same priority. This means that messages are sorted primary by priority: higher priority messages are the first ones extracted by a take, peek or remove action. The second ordering criteria applied is the uniqueId of the entry. The lower uniqueId are returned first (since normally this uniqueId is related to the timestamp, older entries are returned first).
<qos> <queue maxEntries='10000' maxBytes='1000000000' onOverflow='deadMessage'/> </qos>
These parameters allow to configure the queues.
NOTE: Configuration parameters are specified on command line (-someValue 17) or in the
xmlBlaster.properties file (someValue=17). See requirement "util.property" for details.
This page is generated from the requirement XML file xmlBlaster/doc/requirements/queue.xml
Back to overview