Sets, lists, and queues

In the previous examples, we looked at key-value storage provided by Hazelcast maps. However, there are a number of other collections that provide keyless groups of objects. Two of these additional types are distributed versions of collections that you may be already familiar with—sets and lists.

The primary difference between these two collections is that lists allow for multiple entries and a set does not. So, if we add them to the previous map example, we will get the following code:

Set<String> cities = hz.getSet("cities");
cities.addAll(captials.values());
cities.add("London");
cities.add("Rome");
cities.add("New York");

List<String> countries = hz.getList("countries");
countries.addAll(captials.keySet());
countries.add("CA");
countries.add("DE");
countries.add("GB"); // duplicate entry

When using the test console again to interact with these new collections, we will have to use different commands, as we are now interacting with a set and a list rather than a map. You can refer to the help response for further options, but s.iterator and l.iterator will print out the contents of each set and list respectively, as follows:

hazelcast[default] > ns cities
namespace: cities

hazelcast[cities] > s.iterator
1 London
2 New York
3 Paris
4 Rome
5 Washington DC
6 Canberra

hazelcast[cities] > ns countries
namespace: countries

hazelcast[countries] > l.iterator
1 FR
2 AU
3 US
4 GB
5 CA
6 DE
7 GB

The last of the generic storage collections that Hazelcast provides is a queue based on the first-in first-out (FIFO) method. This provides us with a mechanism to offer objects to the back of a queue before retrieving them from the front. Such a structure will be incredibly useful if we have a number of tasks that have to be inpidually handled by a number of client workers.

Let's create a new SimpleQueueExample class again with a main method. However, we're going to create an iterator this time to continuously handle the objects that were taken from the queue, as follows:

import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.HazelcastInstance;

import java.util.concurrent.BlockingQueue;

public class SimpleQueueExample {
  public static void main(String[] args) throws Exception {
    HazelcastInstance hz = Hazelcast.newHazelcastInstance();

    BlockingQueue<String> arrivals = hz.getQueue("arrivals");

    while (true) {
      String arrival = arrivals.take();

      System.err.println(
        "New arrival from: " + arrival);
    }
  }
}

Like we did before, we can use the test console to interact with the queue. This time, we can offer items to the queue for the client to take and print out. A FIFO queue should only provide an inpidual item to a single consumer irrespective of the number of consumers connected to the queue. We can validate that Hazelcast is honoring this behavior by running the example client multiple times, as follows:

hazelcast[default] > ns arrivals
namespace: arrivals

hazelcast[arrivals] > q.offer Heathrow
true

hazelcast[arrivals] > q.offer JFK
true

From the output of the SimpleQueueExample client, we should then be able to see the following messages. If you are running multiple clients by this point, then the output will be spread between them and will certainly not duplicate:

New arrival from: Heathrow

New arrival from: JFK

As mentioned before, queues are great if you wish to provide a single pipeline for work distribution. Items can be concurrently offered onto it before being taken off in parallel by the workers. With Hazelcast ensuring that each item is reliably delivered to a single worker while providing us with the distribution, resilience, and scalability are not present when comparing most alternative queuing systems.