On Mon, Jul 9, 2012 at 5:52 PM, Galder Zamarreño <galder(a)redhat.com> wrote:
On Jul 6, 2012, at 12:44 PM, Mircea Markus wrote:
> ----- Original Message -----
>> From: "Galder Zamarreño" <galder(a)redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev(a)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 :)
+1