Reviving this thread.
It's become a requirement for [1] that we have listeners invoked on the primary data
owner only. I think this is better than a singleton, since you'd have all nodes
sharing the workload of handling events, just that they'd be evenly distributed.
See
https://issues.jboss.org/browse/ISPN-3201 for details.
As for reliability guarantees, we don't have that for listeners in general. I.e., an
event may get missed if a node goes down. So an event being missed or fired on the wrong
node due to a topology change and a change of primary data owner would be expected, IMO.
Cheers
Manik
[1]
http://leads-project.eu/
On 10 Jul 2012, at 07:36, Dan Berindei <dan.berindei(a)gmail.com> wrote:
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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani