Enes Akar, Author at Hazelcast

Hazelcast Tip: Do not forget to shutdown hazelcast on context destroy?

by Enes Akar — Sep 18, 2012

If you use hazelcast in a web application, you should shutdown hazelcast instance on context destroy event.

Otherwise you may experience problem on undeploying/deploying the web container.

public class ContextListener implements ServletContextListener {

public void contextInitialized(ServletContextEvent servletContextEvent) {

}

public void contextDestroyed(ServletContextEvent servletContextEvent) {

yourHazelcastInstance.getLifecycleService().shutdown();

}

}

and web.xml

<listener>
<listener-class>com.hazelcast.twitshirt.ContextListener</listener-class>
</listener>

by Enes Akar — Sep 6, 2012

What is near-cache?

In distributed architectures, obviously remote operations are more costly than local ones so you should try to increase local ops/remote ops. ratio in your system.

Near-cache is a feature that you can increase this ratio for your Hazelcast cluster.

Enabling near-cache, when an object is fetched from remote node, it is put to local cache, so subsequent requests are handled by local node retrieving from local cache.

Of course, this is not free. You gain performance but causes extra memory cost and breaks consistency proportional to lifespan you set for the cached records.

So when to use near-cache?

If your read rate for a map is much higher than write rate, then near-cache makes sense.

Otherwise there will be lots of stale data reads and lots of invalidation messages tripping between nodes.

For details see:

https://hazelcast.com/docs/2.3/manual/single_html/#MapNearCache

by Enes Akar — Sep 5, 2012

When you call mapLocks.unlock(theKey), your lock is auto-garbage-collected. This is simpler, faster and cleaner.

For ILocks, you have to call destroy as all ILock objects are kept in memory.

If you don’t have lots of locks and you want to follow the j.u.c.Lock interface then you can use ILock otherwise IMap is nicer.

by Enes Akar — Jun 27, 2012

Hazelcast and MongoDB

In this article, I will implement a sample (getting-started) project which uses MongoDB as persistence layer for Hazelcast distributed cache.

Hazelcast has a flexible persistence layer, you should just implement an Interface (MapStore) to store your memory grid into your preferred database. By 2.1 version Hazelcast supports MongoDB persistence in a smoother way using Spring-MongoDB data library. Let’s implement a simple project step-by-step to illustrate this feature. Our project will have a single model class and we will see it will persisted to MongoDB when we put it to Hazelcast distributed map.

1- Project Set-Up

I will use Maven. Here the dependencies:

https://gist.github.com/2964861

The dependencies are libraries for projects Spring, Spring-MongoDB,

Hazelcast makes use of Spring Data project, connecting and mapping objects to MongoDB.

2- MongoDB Set-Up

Install and run mongodb in your local machine. One of the things makes mongodb attractive, its quick-start is really quick.

You can follow this guide:

http://www.mongodb.org/display/DOCS/Quickstart

3- Model

A simple POJO to store basic info about users. Only thing you should care, it should be Serializable.

https://gist.github.com/3002226

4- Configuration

As we use Spring, all configuration is bundled in Spring configuration xml. I named the file as beans.xml

https://gist.github.com/2995238

5- Run and Test

Now we can test Mongo-Hazelcast integration. What we will do is to get the user map from spring context and put a new User object into map. We do not add any code related to Mongo or database layer, the object should be saved to MongoDB automatically. Also there is no Hazelcast code in this class. It seems that it just puts an object to a map. But in fact the object is put to distributed data grid, also persisted to MongoDB. The code is so clean thanks to Spring and the Hazelcast’s standart Map implementation.

Here the main class for that:

https://gist.github.com/3002259

And let’s see if it is in Mongo:

MongoDB shell version: 2.0.2
connecting to: test
> db.user.find()
{ “_id” : “id-134”, “_class” : “com.hazelmongo.User”, “name” : “Enes”, “age” : 29 }
>

As you see, Mongo generates two fields other than the ones defined in POJO. _id field is assigned from the key which you used putting to the map. And _class is used to map record the corresponding Java Object.

This sample illustrates the default usage of MongoDB-Hazelcast. You can override default behaviour and object mapping (annotating the POJO) thanks to Spring Data project. Have a look at here for further details.

by Enes Akar — Apr 16, 2012

Distribute with Hazelcast, Persist into HBase In this article, I will implement a solution for a Big Data scenario. I...

by Enes Akar — Apr 5, 2012

This article is a getting-started tutorial on integrating hazelcast into a Spring project.

Part 1: First Create Spring project (if you have already skip to Part 2)

1- Create a maven project.

mvn archetype:generate -DgroupId=spring_hazelcast -DartifactId=spring_hazelcast

2- Add spring dependencies into pom.

https://gist.github.com/2308457

3- Create a TestBean.

https://gist.github.com/2308466

3- Create beans.xml in your source root (src/main/java/beans.xml)

https://gist.github.com/2308478

4- Test your Spring app.

https://gist.github.com/2308514

If you see “success” printed, now we can integrate hazelcast.

Part 2: Integrate Hazelcast

1- Add hazelcast dependencies

https://gist.github.com/2308541

2- Add hz name spaces, hazelcast configuration and an hazelcast map bean to beans xml.

In hz:map definition, “id” is spring bean id, name refers to hazelcast map’s name.

https://gist.github.com/2308666

3- Test hazelcast.

https://gist.github.com/2308679

You can download and browse the getting started project here:

https://github.com/enesakar/spring_hazelcast

by Enes Akar — Apr 3, 2012

Distribute Grails with Hazelcast

In this article I will try to integrate my two favorite technology: grails and hazelcast.

(Bias: I am currently work for Hazelcast)

Ruby on Rails gained popularity among people who seeks productivity on web programming.

Java is often criticisized on being heavy for rapid development.

But richness of Java community has given birth to flexible and dynamic JVM languages like Groovy.

Grails is somewhat synthesis of power of Java (with the help of Groovy) and productivity of Rails with philosophy “convention over configuration”.

Another technology which amazes me is Hazelcast.

I remember the days which I first meet socket programming, RMI; in university.

And when I first tried the Hazelcast my first reaction is “How “Distributing your data over machines” could be so easy.

Single jar, no dependency, distribute your data over maps, queues, topics…

So I have decided to integrate these two technology, write a simple plugin so anyone can easily distribute data over memory by hazelcast.

I called it hazelgrails and pushed it to GitHub: https://github.com/enesakar/hazelgrails

Here introductory on using this plugin.

How to Install Plugin

Run the command:

install-plugin hazelgrails

Configuration

You will see hazelcast.xml in conf directory under plugins directory.

You can configure hazelcast in details.

For available options have a look at:

https://hazelcast.com/docs/2.0/manual/single_html/#Config

To see hazelcast logs add following to Config.groovy:

info ‘com.hazelcast’

Use Hazelcast as Hibernate 2nd Level Cache

In DataSource.groovy replace the following line in hibernate configuration block.

cache.region.factory_class = ‘com.hazelcast.hibernate.HazelcastCacheRegionFactory’

For more details about 2nd level cache configuration have a look at:

https://hazelcast.com/docs/2.0/manual/single_html/#HibernateSecondLevelCache

Test The Plugin

Create an Grails application and install the plugin. Then create a domain and two controllers.

create-domain-class com.hazelgrails.Customer
create-controller com.hazelgrails.Server1
create-controller com.hazelgrails.Server2

As you see, Customer is serializable. Hazelcast requires the objects to be serializable in order to distribute them in cluster.

Now create the war file (command “grails war”) but copy the file with different name (app2.war).

You may deploy the wars into different machines in the same network, or to different servers (Tomcat, Jetty) in same machine or even into the same Tomcat.

For simplicity I have run the current app by “grails run-app” and I have deployed the war to an external Tomcat.

And test them:

http://localhost:9091/TestGrails/server1/index
Output:
Cities:[2:New York, 1:London]
Timestamps:[1333447087796, 1333447112863]
http://localhost:8080/app2/server2/index
Output:
Cities:[2:New York, 1:London]
First customer name:tom, age:20
Timestamps:[1333447087796, 1333447112863]

In practice, if you see the following then you can conclude the nodes formed a cluster succesfully. (you should add “info ‘com.hazelcast’” into Config.groovy)