Get the keys for a Hazelcast Map that belong to partition x

[Jason Clawson]

I have a Hazelcast Map. As you know value in the map is assigned to a
partition based on its key. Its very easy to determine what partition
a key belongs to. What I want to know is: given a partition what keys
does it contain (for a specific map). I can think of a couple of
naive solutions:

1) Iterate over the keys asking each what partition it belongs to
2) Create a multitask that asks each node about its local keys

Is there a better way? And... perhaps there is a better way to solve
my usecase than what I am proposing: I have a map. If a node goes
down I need to be able to determine which map entries were on that
node. I was hoping to do something like... have a cluster listener
that responds to a migration event and basically calls
map.getKeysForPartition(p)

Thanks!

Jason

[Fuad Malikov]

First of all when a node goes down, there will not be a migration events. With 2.0+ the backups are distributed. What will happen is everyone will own it's part of backup. You may listen to membership events but then you need also to keep track of partitions that belonged to each node before and after membership events. 

And the only way of determining the keys that belong to a certain partition is yes to iterate through the keys. Partitions are really virtually. There is no a physical link with keys and partitions inside Hazelcast. 

Fuad Malikov
Co-founder & Managing Partner
Hazelcast | Open source in-memory data grid
Mobile: +90.538.378.9777 | @fuadm

Jason

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To post to this group, send email to haze...@googlegroups.com.
To unsubscribe from this group, send email to hazelcast+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/hazelcast?hl=en.

[Jason Clawson]

Thanks for the info.  I have to say this seems a little counter intuitive.  I know that no data is being transferred when a node goes down.  However, ownership of the partitions change.  To me, it seemed like a migration event is more about this ownership changing than it is about actual data transfer.  The structure of MigrationEvent seems to support this assumption.  I would have expected to see a migration started and completed events happen in succession really quickly (since there is no data to be transferred).

Thanks again for the help.  I would like to +1 for migration events being fired whenever the ownership of partitions change whether that's because of a node going offline or some other occurrence.

Thanks,

Jason

[andrei....@gmail.com]

Hi, 

I fully agree with Jason! It looks strange to receive MigrationEvents only in case a member joins cluster but not when it leaves. 

What is MigrationEvent aimed for then?

Andrei

вторник, 29 мая 2012 г., 19:39:01 UTC+4 пользователь Jason Clawson написал:

[Ali Gürbüz]

Please see https://github.com/hazelcast/hazelcast/issues/1742

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.

To post to this group, send email to haze...@googlegroups.com.

Visit this group at http://groups.google.com/group/hazelcast.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/2b09d0f3-3239-4e8a-89e3-aa440faa232a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[andreas....@gutro.se]

+1 from me as well! 

The usecase I want to use Hazelcast to solve relies on always knowing which keys each node currently own, since each node will hold stateful actors on behalf of these keys. So I need to know if the ownership of a key is moved to/from each node regardless of the reason; migration due to normal re-balancing or if some node goes down etc etc... I was really hoping that this should not matter. In other words, that I always would get notified via migrationCompleted.

Br

Andreas

and  regardless of how the node ended up as the current owner (mi