Multiple instance of Hazelcast on the same JVM (issue 78)

[Talip Ozturk]

Right after the release, I started working on getting multiple
instance of Hazelcast on the same JVM and actually got it working
right now. I even created simple cluster tests. Very useful!

Here is the current API.

HazelcastInstance h1 = Hazelcast.getHazelcastInstance("first");
HazelcastInstance h2 = Hazelcast.getHazelcastInstance("second");

System.out.println(h1.getCluster());
System.out.println(h2.getCluster());

IMap map = h1.getMap("default");
IMap map2 = h2.getMap("default");

map.put ("1", "value");
System.out.println("size " + map2.size());

h1.shutdown();

System.out.println(h2.getCluster());

System.out.println("size " + map2.size());
map2.put ("2", "value2");
System.out.println("size " + map2.size());

Now things to consider:
1. How are we going to pass a custom Config object to the instance?
Alternatives:
a) have Hazelcast.getHazelcastInstance (name, Config);
but what if the instance is already created with the same name and
with a different or default config?
b) do not to have getHazelcastInstance() at all and have
newHazelcastInstance () + new HazelcastInstance (Config) but then you
cannot retrieve the instances by name!

2. Should we get rid of Hazelcast names and go with more meaningful
and completely new names?
such as:
Node node = NodeFactory.getNode ("first");
node.getMap ("mymap");
node.getQueue ("myqueue");

-talip

[Atle Prange]

Hi,

I like option 2)

new HazelcastInstance(Config)

or even better

HazelcastFactory.createInstance(Config)


For clients that need to fetch the instances by name, they can be put in
a Map<String,HazelcastInstance>. I feel that this is the most flexible
option.

(I like the Hazelcast names, everything can be a "Node", but only
Hazelcast can be called "Hazelcast" !)


-atle

[Istvan Soos]

Hi,

1st of all: thanks for the refactoring, I'm looking forward to use it.

> I like option 2)
> new HazelcastInstance(Config)
> or even better
> HazelcastFactory.createInstance(Config)

or both? I'd use the first one in IoC world but the second if
hand-coding (it actually follows the feel of the actual API style).

> (I like the Hazelcast names, everything can be a "Node", but only
> Hazelcast can be called "Hazelcast" !)

I'd stay with the Hazelcast name too, although I could live with the
ClusterFactory too (instead of NodeFactory, because for me a Node is a
single JVM instance). But why would you rename it from Hazelcast? It
seems to be a good name and "brand".

Regards,
Istvan

[Kaloyan Enimanev]

Hi guys,

I would really love to use the new API to write unit tests. This is
currently quite hard to achieve, since

- one cannot boot two Hazelcast instances within the same JVM
- most of the collaboration with Hazelcast is in the form of static
method invocations (e.g. Hazelcast.getMap(), Hazelcast.getInstances()
etc.), that cannot be mocked.

About the questions :

1) Both the styles are supported by the modern IoC containers. I have
no preferences, but just want to point out that by using
Hazelcast.getInstance(), Talip keeps his option to return a
sub-classes of HazelcastInstance. By providing a constructor new
HazelcastInstance() one takes the obligation to always return exactly
HazelcastInstance objects and nothing else.

2) I like the old names better. The plain "Node" conjures up
unpleasant memories about XML parsing. If you feel like the term
"node" describes better a Hazelcast cluster node than the term
"instance", then choose something that will help the developers to
quickly associate the variable definition with Hazelcast e.g.
"HazelcastNode".

best regards,
Kaloyan