Nirvana Channel Attributes
Nirvana channels provide a set of attributes. Depending on the options chosen, these define the behaviour of the events published and stored by the Nirvana Realm Server. Each event published onto a channel has a unique id within the channel called Event Id. Using this event id, it is possible for subscribers to re-subscribe to events on a channel from any given point. The availability of the events on a channel is defined by the chosen attributes of the channel upon creation. Channels can be created either using the Nirvana Enterprise Manager or programmatically using any of the Nirvana Enterprise APIs.
There are a number of important channel attributes which are discussed below
The TTL for a channel defines how long (in milliseconds) each event published to the channel will remain available for subscribers to consume. Specifying a TTL of 0 will mean that events will remain on the channel indefinitely. If you specify a TTL of 10000, then after each event has been on the channel for 10000 milliseconds, it will be automatically removed by the server.
The capacity of a channel defines the maximum number of events may remain on a channel once published. Specifying a capacity of 0 will mean that there is no limit to the number of events on a channel. If you specify a capacity of 10000, then if there are 10000 events on a channel, and another event is published to the channel, the 1st event will be automatically removed by the server.
Nirvana channels can be of 5 different types, simple, reliable, persistent, mixed and transient. The difference lies in the type of physical storage used for each type and the performance overhead associated with each type.
Persistent channels have their messages stored in the Nirvana Realm's persistent channel disk based store. The persistent channel store is a high performance file based store that uses a separate file for each channel on that Realm facilitating migrating whole channels to different Realms. All messages published to a persistent channel 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 channel are marked as deleted however the store size will not be reduced until maintenance is performed on the channel using the Nirvana Enterprise Manager or an Administration AIP call. This augments the high performance of the Nirvana Realm.
Mixed channels allow the users to specify whether the event is stored persistently or in memory as well as the Time To Live (TTL) of the individual event. On construction of a Mixed channel the TTL and Capacity can be set, if the user supplies a TTL for an event this is used instead of the channel TTL
Reliable channels 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 all messages across all reliable channels 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 channels will be removed from the channel as a matter of policy. However, as Nirvana guarantees not to ever reuse event ids within a channel, new messages published in those channels will get assigned event ids incremented from the event id of the last message prior to the previous instance stopping.
Simple channels have their messages stored in the Nirvana Realm's own memory space supplying a high-speed channel type. The difference between a Simple and Reliable is the fact that the event ids are reset to 0 in a Simple channel whenever the Nirvana Server is restarted.
A transient channel is like a simple channel in that no event characteristics are stored persistently. In addition to this, data is only ever written to a transient channel when 1 or more consumers are connected to the channel and are able to consume said data. Unlike the simple channel which stores event data in memory transient channels do not store anything, not even in memory. Transient channels can be thought of as a relay between 1 or more publishers and 1 or more subscribers.
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
Additional Channel Attributes
In addition to the 3 attributes above which define storage behavior for events, there are a number of other important attributes that can be set for a channel.
Dead Event Store
When events are removed automatically, either by the capacity policy of the channel or the age (TTL) policy of the events itself and they have not been consumed, it may be a requirement for those events to be processed separately. If so, channels or queues can be created with a dead event store so any events that are purged automatically from that have not been consumed will be moved into the dead event store. Dead event stores themselves can be a channel or a queue and can be created with any attributes you wish.
Channels can also be created with a set of channel keys which define how channel events can be managed based on the content of the events. For more information, please see the Channel Publish Keys section
The cluster wide flag indicates that a channel is created on all cluster realm nodes. For more information on clustering please see our clustering section.
There are 2 types of optional engine which a channel can use: