----- Original Message -----
> From: "Dan Berindei" <dan.berindei@gmail.com>
> To: "infinispan -Dev List" <infinispan-dev@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@redhat.com >
> wrote:
>
>
>
> ----- Original Message -----
> > From: "Galder Zamarreño" < galder@redhat.com >
> > To: "infinispan -Dev List" < infinispan-dev@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.