[infinispan-dev] singleton @Listeners

[Manik Surtani]

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 at gmail.com> wrote:

> 
> On Mon, Jul 9, 2012 at 5:52 PM, Galder Zamarreño <galder at redhat.com> wrote:
> 
> 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 :)
> 
> 
> +1
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130829/1f190d5e/attachment-0001.html