Listeners and map lifecycle

[Paul]

Hi Guys,

Is there a way to register a listener on a given map prior to that
cache becoming active on a given node.

Here's the scenario:

You have an active cluster; a new node joins which needs to receive
notifications of all local events for a map. I want to avoid the race
condition between partitions being migrated to this node (and hence
generating EntryEvents) and registering the listener.

Advice gratefully received.

Thanks, Paul

[Mehmet Dogan]

EntryEvents are not fired during partition migration. 

@mmdogan

--
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.

[Paul]

Thanks, but I still think there's a race condition.

I need a way to ensure that my entry listener is attached prior to receiving any entry events for a given map. I believe I'm right in saying that partition arriving/arrived and entry events are all fired asynchronously on different threads, so even if I could get a MigrationListener registered during the node bootstrap* and that listener registered a LocalEntryListener on the map, I wouldn't be able to guarantee that the listener would be registered prior to the first EntryEvent arriving.

*I'm not sure how I might do this.

My ideal solution would be to define a LocalEntryListener as part of the map config...

Thanks, Paul

[Mehmet Dogan]

You are right, there is a race condition. There is no way to guarantee that a listener registration happens before an event is fired, and defining listeners in configuration solves this race condition problem. Please create an issue regarding this case.

@mmdogan

Thanks, Paul

--

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

To view this discussion on the web visit https://groups.google.com/d/msg/hazelcast/-/_stB18wsjy8J.

[Paul]

Thanks for the clarification. I've raised http://code.google.com/p/hazelcast/issues/detail?id=705.

Am I also right in thinking that as arriving/arrived and entry events are all fired on separate threads, there is no guarantee that they will arrive in order? This will pose a bit of a problem for us.

I know the idea of key-level partition arrival events has been rejected previously, howeverI was wondering if the developers might reconsider as it is critical to some clustered architectures. In conjunction with the listeners I've requested it makes a lot of sense.

Thanks, Paul

[Talip Ozturk]

> Am I also right in thinking that as arriving/arrived and entry events are
> all fired on separate threads, there is no guarantee that they will arrive
> in order? This will pose a bit of a problem for us.

Hazelcast node receives the events in order then calls your listeners
in parallel for separate keys. But events for the same key will be
fired in order; this is guaranteed.

-talip

[Paul]

Per-key ordering is very good news.

The problem is, however, that if I need to generate entry arrival events, I can't guarantee that MigrationListener#migrationCompleted() will be called before the first EntryEvent is triggered on the EntryListener because they're on separate threads. The only solution I can see would be for Hazelcast to generate these arrival events and use the same affinity between event thread and key as for EntryEvents.

[Zack Radick]

Paul,

Not sure if it helps but to get around this race condition on registering interest in a map and adding an entry listener I simply do the following:

 

final MultiMap<KEY, VALUE> multiMap = hazelcast.getMultiMap( multiMapQueueName );
multiMap.addLocalEntryListener( this );
for( KEY key : multiMap.localKeySet() )
   deque.offer( key );

In my scenario I have a deque of keys that I work locally and I expect there is a possibility of working something more than once and handle that appropriately.  This just makes sure I have at least one key per local entry.  Seems to work fine for my needs until the race condition can be truly eliminated.

 

Cheers,

--Zack

On Wed, Oct 12, 2011 at 5:41 AM, Paul <paul.w...@gmail.com> wrote:

Per-key ordering is very good news.

The problem is, however, that if I need to generate entry arrival events, I can't guarantee that MigrationListener#migrationCompleted() will be called before the first EntryEvent is triggered on the EntryListener because they're on separate threads. The only solution I can see would be for Hazelcast to generate these arrival events and use the same affinity between event thread and key as for EntryEvents.

--

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

To view this discussion on the web visit https://groups.google.com/d/msg/hazelcast/-/B-NyzclgjdIJ.

[Paul]

Hi Zack,

That makes sense; you effectively have a continuous query filtered for local keys only.

Thanks, Paul