[infinispan-dev] singleton @Listeners

[Dan Berindei]

On Fri, Jul 6, 2012 at 3:10 PM, Mircea Markus <mmarkus at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Dan Berindei" <dan.berindei at gmail.com>
> > To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> > Sent: Friday, July 6, 2012 12:43:44 PM
> > Subject: Re: [infinispan-dev] singleton @Listeners
> >
> >
> >
> > On Fri, Jul 6, 2012 at 1:44 PM, Mircea Markus < mmarkus at redhat.com >
> > 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.
> >
> > >
> >
> >
> > If we add the attribute we're going to raise some new questions:
> > * Is the listener guaranteed to fire on the primary owner?
> > * If two keys are Group-ed together, is the listener guaranteed to
> > fire on the same node for both keys? What if a new node becomes the
> > primary owner between the two modifications?
> I'd rather not offer any such explicit guarantees but the uniqueness of
> execution. If users are concerned with the locality of the events they
> should use the general @Listener interface and figure it out internally.
>
> > * If the key is modified by the same put command on two owners, and
> > each node is the primary owner of the key at the moment when it
> > receives the put command, does the listener fire on still fire only
> > once?
> I guess that might be a tricky one, as once-and-only-once guarantee is
> tricky to implement...
>
> >
> >
> >
> >
> > > 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 :)
> >
> >
> >
> >
> >
> > I think what C2B2 are doing is more like replicated listeners in a
> > distributed cache. They probably had to post the message on JMS only
> > from the primary owner, but the blog doesn't mention it, so I don't
> > think it was that hard to figure it out ;)
>
> They post the message to the JMS from all the owners and the used HormetQ
> stuff to remove duplicated messages. It doesn't seem like they thought
> about the primary-owenr approach, but that would have helped.
>
>
I see, they only describe that in part 2.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120706/994e4fb5/attachment-0001.html