Nirvana Queue Attributes

Nirvana channels provide 3 main attributes. Depending on the options chosen, these define the behaviour of the events published and stored by the Nirvana Realm Server. The availability of the events on a queue is defined by the chosen attributes of the queue upon creation. The main attributes are:

Each of these attributes are described in the following sections.

Queue TTL

The TTL for a queue defines how long (in milliseconds) each event published to the queue will remain available to consumers. Specifying a TTL of 0 will mean that events will remain on the queue indefinitely. If you specify a TTL of 10000, then after each event has been on the queue for 10000 milliseconds, it will be automatically removed by the server.

Queue Capacity

The capacity of a queue defines the maximum number of events may remain on a queue once published. Specifying a capacity of 0 will mean that there is no limit to the number of events on a queue. If you specify a capacity of 10000, then if there are 10000 events on a queue, and another event is published to the queue, the 1st event will be automatically removed by the server.

Queue Type

Nirvana queues can be of 4 different types, simple, reliable, persistent and mixed. The difference lies in the type of physical storage used for each type and the performance overhead associated with each type.

Simple Queues

Simple queues have their messages stored in the Nirvana Realm’s own memory space supplying a high-speed queue type. The difference between a Simple and Reliable is the fact that the event ids are reset to 0 in a Simple queue whenever the Nirvana Server is restarted.

Reliable Queues

Reliable queues have their messages stored in the Nirvana Realm’s own memory space. The first fact that is implied is that the maximum number of bytes that that all messages across all reliable queues within a Nirvana Realm is limited by the maximum heap size available to the Java Virtual Machine hosting that Realm. The second fact implied is that if the Nirvana Realm is restarted for any reason, all messages stored on reliable queues will be removed from the queue as a matter of policy. However, as Nirvana guarantees not to ever reuse event ids within a queue, new messages published in those queues will get assigned event ids incremented from the event id of the last message prior to the previous instance stopping.

Persistent Queues

Persistent queues have their messages stored in the Nirvana Realm’s persistent queue disk based store. The persistent queue store is a high performance file based store that uses a separate file for each queue on that Realm facilitating migrating whole queues to different Realms. All messages published to a persistent queue will be stored to disk, hence it is guaranteed that they will be kept and delivered to subscribers until it is purged or removed as a result of a TTL or capacity policy. Messages purged from a persistent queue are marked as deleted however the store size will not be reduced until maintenance is performed on the queue using the Nirvana AdminTool. This augments the high performance of the Nirvana Realm.

Mixed Queues

Mixed queues allow the users to specify whether the event is stored persistently or in memory as well as that the Time To Live (TTL) of the individual event. On construction of a Mixed queue the TTL and Capacity can be set, if the user supplies a TTL for an event this is used instead of the queue

Storage Properties

This storage properties pannel allows for configuration of advanced storage properties, a summary of these properties can be seen below:

  • Auto Maintenance: Controls whether persistent store is maintained automatically (ie events reaching their TTL, or events which have been purged are cleared from the channel storage file.

  • Honour Capacity: Whether the channel / queue capacity setting will prevent publishing of any more data once full. If true, the client will get an exception on further publishes (a transactional publish will receive an exception on the commit call, a non transactional publish will receive an asynchronous exception through the nAsyncExceptionHandler). If false the oldest event will be purged to make room for the newest.

  • Enable Caching: Control the caching algorithm within the server, if you set caching to false, all events will be read from the file store. If true then if server has room in memory, they will be stored in memory and reused.

  • Cache on Reload: When a server restarts it will scan all file based stores and check for corruption. During this test the default behaviour is to disable caching to conserve memory, however, in some instances it would be better if the server had actually cached the events in memory for fast replay.

  • Enable Read Buffering: Control the read buffering logic for the store on the server.

  • Read Buffer Size: If ReadBuffering is enabled then this function sets the size in bytes of the buffer to use.

  • Sync Each Write: Control whether each write to the store will also call sync on the file system to ensure all data is written to the Disk

  • Sync Batch Size: Control how often in terms of number of events to sync on the file system to ensure all data is written to the Disk

  • Sync Batch Time: Control how often in terms of time elapsed to sync on the file system to ensure all data is written to the Disk

  • Fanout Archive Target: Control whether all events fanned out are written to an archive q