Sets, lists, and queues

In our previous examples, we have 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 we are hopefully already familiar with—sets and lists.

As we know, the primary difference between the two is that lists allow for multiple entries and a set does not. So if we add them to our previous map example, we 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

In using our 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 for sets and lists respectively.

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 first-in first-out (FIFO) based queue. This provides us with a mechanism to offer objects onto the top of a queue before retrieving them off the bottom. Such a structure would be incredibly useful if we had a number of tasks to individually handle by a number of client workers.

Let create a new SimpleQueueExample class again with a main method, but this time we're going to create an iterator to continuously handle objects taken from the queue.

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 before, we can use our test console to interact with the queue. This time we can offer items to the queue for our client to take and print out. A FIFO queue should only provide an individual 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 our example client multiple times.

hazelcast[default] > ns arrivals
namespace: arrivals
hazelcast[default] > q.offer Heathrow
true

hazelcast[arrivals] > q.offer JFK
true

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

New arrival from: Heathrow

New arrival from: JFK

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