<div class="gmail_quote">On Fri, Jul 6, 2012 at 3:10 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
<br>
----- Original Message -----<br>
> From: "Dan Berindei" <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>><br>
> To: "infinispan -Dev List" <<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>><br>
</div><div><div class="h5">> Sent: Friday, July 6, 2012 12:43:44 PM<br>
> Subject: Re: [infinispan-dev] singleton @Listeners<br>
><br>
><br>
><br>
> On Fri, Jul 6, 2012 at 1:44 PM, Mircea Markus < <a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a> ><br>
> wrote:<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
> > From: "Galder Zamarreño" < <a href="mailto:galder@redhat.com">galder@redhat.com</a> ><br>
> > To: "infinispan -Dev List" < <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a> ><br>
><br>
> > Sent: Friday, July 6, 2012 2:46:20 AM<br>
> > Subject: Re: [infinispan-dev] singleton @Listeners<br>
> ><br>
> ><br>
><br>
> > On Jun 28, 2012, at 11:26 AM, Mircea Markus wrote:<br>
> ><br>
> > > This is a problem that pops up constantly:<br>
> > > User: "I add a listener to my distributed/replicated cache but<br>
> > > this gets invoked numOwners times - can I make that to be invoked<br>
> > > only once cluster wise?"<br>
> > > Developer: "Yes, you can! You have to do that and that..."<br>
> > ><br>
> > > What about a "singleton" attribute on the Listener? Would make<br>
> > > the<br>
> > > reply shorter:<br>
> > > Developer: "Use @Listener(singleton=true)"<br>
> ><br>
> > Hmmm, that seems doable without any extra attributes.<br>
> ><br>
> > For a replicated cache, take the view and pick a node (consistently<br>
> ><br>
><br>
> > For a distributed cache, find the primary owner of a key.<br>
> That's pretty much how I had in mind to implement it. But I think the<br>
> attribute is needed though: there are use cases in which you still<br>
> want to be notified on all the owners, as you do now. OTOH if you<br>
> only want a per-cluster notification you'd add this attribute to the<br>
> listener.<br>
><br>
> ><br>
><br>
><br>
> If we add the attribute we're going to raise some new questions:<br>
> * Is the listener guaranteed to fire on the primary owner?<br>
> * If two keys are Group-ed together, is the listener guaranteed to<br>
> fire on the same node for both keys? What if a new node becomes the<br>
> primary owner between the two modifications?<br>
</div></div>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.<br>
<div class="im"><br>
> * If the key is modified by the same put command on two owners, and<br>
> each node is the primary owner of the key at the moment when it<br>
> receives the put command, does the listener fire on still fire only<br>
> once?<br>
</div>I guess that might be a tricky one, as once-and-only-once guarantee is tricky to implement...<br>
<div class="im"><br>
><br>
><br>
><br>
><br>
> > Has this been asked so often? I don't recall right now… :)<br>
> Yes, CBOE had the same issue as they needed to push updates from one<br>
> cluster to the other over hotrod.<br>
> Also in this article they have to do quite a workaround to enforce<br>
> uniqueness:<br>
> <a href="http://blog.c2b2.co.uk/2012/06/infinispan-event-push-to-tomcat.html" target="_blank">blog.c2b2.co.uk/2012/06/infinispan-event-push-to-tomcat.html</a><br>
> And there were some others :)<br>
><br>
><br>
><br>
><br>
><br>
> I think what C2B2 are doing is more like replicated listeners in a<br>
> distributed cache. They probably had to post the message on JMS only<br>
> from the primary owner, but the blog doesn't mention it, so I don't<br>
> think it was that hard to figure it out ;)<br>
<br>
</div>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.<br>
<br></blockquote><div><br>I see, they only describe that in part 2.<br></div></div><br>