Force put objects to Hazelcast local map

0
votes

We are working on a distributed data processing system, and Hazelcast is one of the component we are using.

We have a streaming data input coming to the cluster and we have to process the data (update/accumulate etc). There is distributed request map, which has local entry listeners. We process a new request (update/accumulate in memory) and put to another distributed map, which is the actual datagrid.

Thus we can process each request concurrently without locking. However, the putting of data to the main datagrid might involve a network trip.

Is there a way I can force specify which node to be selected? Basically I would want to put it in the local map for datagrid. This should improve the overall throughput by avoiding the network trip.

By using a partition aware key, I can specify that all such keys go to the same partition, however, I am looking to actually 'specify' the partition. Is this possible?

1
javahazelcast
Have you tried to ask your question on the Hazelcast Google Group? Or considered a professional support? Btw: the best way to avoid the network trip is to abandon a distributed data structure :) Really. Because being distributed is also related to some network overhead. – G. Demecki
@GrzesiekD.Thanks for your response. Will post it to the the google group as well. Somehow, my initial instinct is to post in SO :). Actually, we need the data redundancy as present in for fault tolerance in the cluster. So, I cannot actually eliminate distributed totally, just trying to minimize it, if you say. – sutanu dalui
was there any solution to your problem? as I m dealing with the exact same thing – kosta5

1 Answers

1
votes

You can create a key for a specific partition. We do this often for testing.

Once you have created such a key for every partition, you can use

map.put("yourkey@partitionkey", value)

Checkout out the git repo and look for HazelcastTestSupport.generateKeyOwnedBy(hz).

Important: it can be that a partition belongs to a member at some point in time, but a partition can move around in the system. E.g. when member joins/leaves the cluster, so the solution could be fragile.