Ignite In-Memory Data Fabric, in addition to providing standard key-value map-like storage, also provides an implementation of a fast Distributed Blocking Queue and Distributed Set.
IgniteSet, an implementation of
java.util.Set interface respectively, also support all operations from
java.util.Collection interface. Both, queue and set can be created in either collocated or non-collocated mode.
Below is an example of how to create a distributed queue and set.
Ignite ignite = Ignition.ignite(); IgniteQueue<String> queue = ignite.queue( "queueName", // Queue name. 0, // Queue capacity. 0 for unbounded queue. new CollectionConfiguration() // Collection configuration. );
Ignite ignite = Ignition.ignite(); IgniteSet<String> set = ignite.set( "setName", // Set name. new CollectionConfiguration() // Collection configuration. );
If you plan to create just a few queues or sets containing lots of data, then you would create them in non-collocated mode. This will make sure that about equal portion of each queue or set will be stored on each cluster node. On the other hand, if you plan to have many queues or sets, relatively small in size (compared to the whole cache), then you would most likely create them in collocated mode. In this mode all queue or set elements will be stored on the same cluster node, but about equal amount of queues/sets will be assigned to every node.
A collocated queue and set can be created by setting the
collocated property of
CollectionConfiguration, like so:
Ignite ignite = Ignition.ignite(); CollectionConfiguration colCfg = new CollectionConfiguration(); colCfg.setCollocated(true); // Create collocated queue. IgniteQueue<String> queue = ignite.queue("queueName", 0, colCfg);
Ignite ignite = Ignition.ignite(); CollectionConfiguration colCfg = new CollectionConfiguration(); colCfg.setCollocated(true); // Create collocated set. IgniteSet<String> set = ignite.set("setName", colCfg);
Non-collocated mode only makes sense for and is only supported for
Given that elements will remain in the queue until someone takes them, and that no two nodes should ever receive the same element from the queue, cache queues can be used as an alternate work distribution and load balancing approach within Ignite.
For example, you could simply add computations, such as instances of
IgniteRunnable to a queue, and have threads on remote nodes call
IgniteQueue.take() method which will block if queue is empty. Once the
take() method will return a job, a thread will process it and call
take() again to get the next job. Given this approach, threads on remote nodes will only start working on the next job when they have completed the previous one, hence creating ideally balanced system where every node only takes the number of jobs it can process, and not more.
Ignite collections can be in configured in API via
CollectionConfiguration (see above examples). The following configuration parameters can be used:
Sets collocation mode.
Sets underlying cache mode (
Sets underlying cache atomicity mode (
Sets underlying cache memory mode (
Sets offheap maximum memory size.
Sets number of backups.
Sets optional predicate specifying on which nodes entries should be stored.