Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

Session listener called twice

Hi, From a class for which I have as starting point SpaceModeContextBean from your documentation I register a a session listener on lease expire event for a template. The object for which event's I listen I also write from the PU and my goal is to do something after a certain time (= the lease): client writes some objects with a @SpaceRouting property, for each a polling container writes TimerObject with the same value for routing field and my listener listens for lease expire of TimerObject.

The problem appears if I do this with 2 GSCs each holding the backup of the other with the following schema: <os-sla:sla cluster-schema="partitioned-sync2backup" number-of-instances="2" number-of-backups="1" max-instances-per-vm="1"> </os-sla:sla>

In this setup the listener is called twice for each TimerObject that expires. From my log:

15 Ian 2010 11:15:36,852 EET INFO [LRMI Connection-pool-4-thread-3] [SomeClass] Setup listener 9003160 from "SomeClass:hash:19185231" 15 Ian 2010 11:15:36,867 EET INFO [LRMI Connection-pool-4-thread-5] [SomeClass] Setup listener 26289835 from "SomeClass:hash:8498575" ....................... 15 Ian 2010 11:27:47,163 EET INFO [LRMI Connection-pool-4-thread-2] [SomeClass] Nottified at "SomeClass:hash:19185231", listener hash 9003160 15 Ian 2010 11:27:47,428 EET INFO [Notifier-pool-8-thread-1] [SomeClass] Notiffied at "SomeClass:hash:19185231" listener hash 9003160

You can see in those logs the hashcode of the objects. SomeClass is the class from where I setup the listener and the two instances are from the two GSCs (lines 1,3,4 from logs are from the same GSC console, and line 2 is from the other one). As you can see the same listener is nottifed twice .

Is this normal behavior and I missuse something? Or as I expected I should get a single notification?

Thanks, Lucian

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=3349]{quote}

asked 2010-01-15 05:47:13 -0500

lukeh gravatar image

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

That's the expected behavior. The doc describe this. You will be getting the lease expiration notification both from the primary and backup in case you have such running. We will resolve this issue in future releases. Shay

answered 2010-01-15 06:54:13 -0500

shay hassidim gravatar image
edit flag offensive delete link more


Thanks Shay, I must have overlooked that part of documentation. I still have some questions: 1. Is there a way to see if the event comes from the backup? Based on the event object or something? 2. If I change my implementation to use a notify container it will still happen the same? 3. In the approach with notify container is it guaranteed that the LEASE_EXPIRE event will be delivered to the new elected primary if the expiration happens during failover? Regards, Lucian

lukeh gravatar image lukeh  ( 2010-01-15 08:31:43 -0500 )edit
  1. It is doable. But would require some work.
  2. NO (in case it is running remotely). See below comment when running in collocated mode.
  3. Since the notification delivered both from the primary and backup you will never loose this event.

Every space runs its own autonomic lease manager. This is the one that is responsible to send the notifications back to the caller. That's why you get this event from both the primary and the backup. We will enhance this functionality in the future to be a bit more coordinated to avoid this redundancy in case the user is not interested with it.

The question is - can you build your business logic in such a way that it will relay on a different mechanism that would avoid the need to identify duplicated events? For example: - run the listener collocated with the space (can be done with a notify container) and not as a remote client and do not replicate notify template . In such a case the notify container will not be active at the backup (will be started only when the backup will turn to be a primary) and the notify registration will be alive only at the primary. See more here: http://www.gigaspaces.com/wiki/displa... and the replicateNotifyTemplate setting for the notify container). - use a timer to identify when the object has been expired. This is obviously relevant only when you have very small amount of objects that expire and you want to perform some activity once they expire. Shay


Edited by: Shay Hassidim on Jan 15, 2010 10:04 AM

shay hassidim gravatar image shay hassidim  ( 2010-01-15 10:04:05 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2010-01-15 05:47:13 -0500

Seen: 59 times

Last updated: Jan 15 '10