<br><div class="gmail_quote">On Mon, Jul 9, 2012 at 5:52 PM, Galder Zamarreño <span dir="ltr"><<a href="mailto:galder@redhat.com" target="_blank">galder@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>
On Jul 6, 2012, at 12:44 PM, Mircea Markus wrote:<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>
>> Sent: Friday, July 6, 2012 2:46:20 AM<br>
>> Subject: Re: [infinispan-dev] singleton @Listeners<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 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>
>> 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 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.<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 cluster to the other over hotrod.<br>
> Also in this article they have to do quite a workaround to enforce uniqueness: <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>
</div>Ok. I'm thinking about the priority of this.<br>
<br>
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.<br>
<br>
So, I think what we should do now is:<br>
<br>
1. Document the patterns to get around the problem that you explain.<br>
<br>
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<br>
<br>
My 2 pesetas :)<br>
<br>
</blockquote></div><br>+1<br>