[infinispan-dev] singleton @Listeners

Galder Zamarreño galder at redhat.com
Mon Jul 9 10:52:42 EDT 2012


On Jul 6, 2012, at 12:44 PM, Mircea Markus wrote:

> ----- Original Message -----
>> From: "Galder Zamarreño" <galder at redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Sent: Friday, July 6, 2012 2:46:20 AM
>> Subject: Re: [infinispan-dev] singleton @Listeners
>> 
>> 
>> On Jun 28, 2012, at 11:26 AM, Mircea Markus wrote:
>> 
>>> This is a problem that pops up constantly:
>>> User:      "I add a listener to my distributed/replicated cache but
>>> this gets invoked numOwners times - can I make that to be invoked
>>> only once cluster wise?"
>>> Developer: "Yes, you can! You have to do that and that..."
>>> 
>>> What about a "singleton" attribute on the Listener? Would make the
>>> reply shorter:
>>> Developer: "Use @Listener(singleton=true)"
>> 
>> Hmmm, that seems doable without any extra attributes.
>> 
>> For a replicated cache, take the view and pick a node (consistently
>> 
>> For a distributed cache, find the primary owner of a key.
> That's pretty much how I had in mind to implement it. But I think the attribute is needed though: there are use cases in which you still want to be notified on all the owners, as you do now. OTOH if you only want a per-cluster notification you'd add this attribute to the listener.
>> 
>> Has this been asked so often? I don't recall right now… :)
> Yes, CBOE had the same issue as they needed to push updates from one cluster to the other over hotrod.
> Also in this article they have to do quite a workaround to enforce uniqueness:  blog.c2b2.co.uk/2012/06/infinispan-event-push-to-tomcat.html
> And there were some others :)

Ok. I'm thinking about the priority of this.

I think our listeners are very buggy, as I've already ranted a few times (thread safety guarantees, plus rather akward programming model), but the agreement was to not touch them till we get around to implementing JSR-107 notifications.

So, I think what we should do now is:

1. Document the patterns to get around the problem that you explain.

2. Hold of implementing any new listener functionality cos it's quite likely gonna need reimplementing one way or the other when we get around to JSR-107

My 2 pesetas :)

Cheers,

> 
>> 
>>> 
>>> Cheers,
>>> Mircea
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache




More information about the infinispan-dev mailing list