Is it possible to replace Hazlecast with another shared memory technology?

[Asaf Lahav]

Hi,

I was wondering whether its possible to replace Hazlecast with a different in memory cache technology? I would rather use redis or ehcache as these are supported technologies by our ops teams.

If yes, how?

Thank you...

[Jordan Halterman]

Hazelcast is really used by Vert.x for cluster management and sharing event bus addresses across the cluster. There isn't any user API for Hazelcast in Vert.x 2, but the cluster manager is pluggable. The Vert.x ClusterManager API requires that the implementation can trigger an event when a node joins or leaves the cluster and can provide a cluster-wide shared map. But technologies like Redis don't do that. Of course, you can still use one of those technologies for caching as Hazelcast is just used for node discovery and some internal data structures as I mentioned.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Iván Zahoránszky]

Hi Kuujo,

I would have a different but related question. I use Vert.x 2.1.2 and as far as I can see you are only able to change the cluster manager if you run your modules as fat jars with

java -Dvertx.clusterManagerFactory=YourClusterManagerFactory -jar you-fat.jar -cluster -cp your-cluster-mgr.jar

Is it the case? Because only the FatJarStarter.java uses the vertx.clusterManagerFactory VM argument.

And if this is the case do you plan to make it possible when you run your modules with vert.x like

vertx runmod ...

Thx,

Iván

[Stream]

Yes, since ClusterManager have been exposed as SPI, you could implement it with other technologies, i have implement it with zookeeper in vert.x3.   https://github.com/vert-x3/ext/pull/3

[Nick Scavelli]

On Thursday, November 6, 2014 5:04:57 AM UTC-5, Iván Zahoránszky wrote:

Hi Kuujo,

I would have a different but related question. I use Vert.x 2.1.2 and as far as I can see you are only able to change the cluster manager if you run your modules as fat jars with

java -Dvertx.clusterManagerFactory=YourClusterManagerFactory -jar you-fat.jar -cluster -cp your-cluster-mgr.jar

Is it the case? Because only the FatJarStarter.java uses the vertx.clusterManagerFactory VM argument.

No not true, look at the constructor for DefaultVertx for the logic in determining the cluster manager.

 

And if this is the case do you plan to make it possible when you run your modules with vert.x like

vertx runmod ...

You should be able to use the same property, but you have to pass it in differently since you are running the vertx script as apposed to the java executable you use for fatjar

So for example:

$ VERTX_OPTS="-Dvertx.clusterManagerFactory=YourClusterManagerFactory" vertx runmod ...

[Iván Zahoránszky]

Sorry I have not noticed that. Thanks for the quick answer.

Iván

[Fabio Marinelli]

Hi guys, 

just wanted to mention that I'm working to integrate 2 new clustermanager (infinispan and jgroups)

It's a work in progress but still if you are interested or have any ideas let me know :)

https://github.com/redhat-italy/vert.x/tree/jgroups-clustermanager

cheers

[javadevmtl]

Hi like people already mentioned. Hazlecast in Vert.x 2.x is used for cluster discovery only. In vert.x 3.x they will have shared map also. But this will not and doesn't stop you from using any other caching technologies.

I successfully used gigaspaces and gridgain with Vertx. Just put what ever jars you need in your module lib folder and use in your verticles as required. Just be aware of the caching technology and check to see if it's APIs are true async or blocking, so you can decide if you will use standard verticles or worker verticles.