On the following page, we show our example application
can be implemented using Hazelcast in client-server mode.


Hazelcast’s Native Clients
provide a way to do all Hazelcast operations without being a member of the cluster.
That way, Hazelcast’s existing peer-to-peer mode
can be run on dedicated server hardware, while application servers deploy native clients to
interact with the servers.


As the underlying implementation is the same, Hazelcast’s client-server deployment
has the same properties as the peer-to-peer deployment.


The following initialization code creates a Hazelcast Native Client
and configures it programmatically. The server addresses are
hard-coded as localhost:5701 and localhost:5702:

public void contextInitialized(ServletContextEvent servletContextEvent) {
    ClientConfig clientConfig = new ClientConfig();
    clientConfig.addAddress("localhost:5701", "localhost:5702");
    HazelcastInstance client = HazelcastClient.newHazelcastClient(clientConfig);
    ConcurrentMap<String, UserEventList> map = client.getMap("events");
    ServletContext context = servletContextEvent.getServletContext();
    context.setAttribute("map", map);

The REST interface loads the Cache the same way as
in the peer-to-peer example:

// ...
private ServletContext context;
private ConcurrentMap<String, UserEventList> map;

public void init() {
    map = (ConcurrentMap) context.getAttribute(CACHE);


public void contextDestroyed(ServletContextEvent servletContextEvent) {


public void appendEvent(@PathParam("user") String user, String msg) {
    boolean success;
    map.putIfAbsent(user, UserEventList.emptyList());
    do {
        UserEventList oldMsgList = map.get(user);
        UserEventList newMsgList = UserEventList.append(oldMsgList, msg);
        success = map.replace(user, oldMsgList, newMsgList);
    while ( ! success );


public List<String> searchByUser(@PathParam("user") String user) {
    UserEventList result = map.get(user);
    if ( result == null ) {
        return new ArrayList<>();
    return result.getMessages();




How to Run


A script server.sh is included in Hazelcast’s hazelcast-2.5.zip
distribution. However, if the script is run as it is, it will not be
possible to store UserEventList objects on the server, as that class
is defined in the
common JAR of our example application.

Our example code is hosted on GitHub.
The file common/target/common-0.1.jar is created when the example project
built with maven.

Hazelcast’s server.sh needs to be edited, and common/target/common-0.1.jar
must be added to the classpath. After that, Hazelcast’s server instances can be
started with

sh ./server.sh


The clients are run as follows:

Instance 1:

mvn tomcat7:run-war -pl part04.hazelcast -am verify -Dmaven.tomcat.port=8080

Instance 2:

mvn tomcat7:run-war -pl part04.hazelcast -am verify -Dmaven.tomcat.port=9090

The Web interfaces are then available via

Advanced Topics

Apart from the Native Clients shown above, Hazelcast also supports
Lite Members.
Both, native clients and lite members do not store data.
However, lite members are part of the distributed hash table,
i.e. they have a socket connection to every member in the cluster and know which
node is responsable for which key range.

When the number of clients is small, lite members may perform better,
as they can access data much faster. If the number of clients is high
or if the clients are connected through the WAN,
native clients perform better as they do not require so much networking


The final page of part 4 of our series shows how our example application
can be implemented using Infinispan in client-server mode: