On 22 Feb 2012, at 10:05, Galder Zamarreño wrote: >> >>> For 2, imagine a client that starts a remote cache manager, signs up for >>> notifications in cache C, and has 50 threads interacting with cache C >>> concurrently (so, 50 channels are open with the server). I don't want the >>> server to send back 50 events for each interested cache operation that >>> happens on the server side. 1 notification should be enough. This is one of >>> the reasons I want "option #1". >> >> Yes, the server definitely needs to be smart enough to identify multiple >> connections from the same client, and this also needs to be distributed. > > +1, but the question is, how do you define "same client"? This is what I was > getting to with "origin" earlier (a way to identify cache managers). You > can't assume that a client IP to differentiate between different clients cos > you could have multiple Hot Rod clients running independently in a machine. > > If you have any other ideas, I'm happy to hear
Each client could be assigned a UUID when it first connects… and subsequent messages could include this UUID in a header. Hmm, could get expensive though. > >> E.g., if client C is connected to 2 server nodes S1 and S2, we don't want >> both S1 and S2 to send back the same notification, > > +1 again, this can very easily done by using the isLocal() call in listeners. > I was only planning to send notifications from the node where the operation > is local, which gets around this issue. +1. >> Also, what are your thoughts around batching notifications? > > This could be handy to avoid overloading clients as well, but wasn't in my > initial plans. > > What might be important at this stage is if we consider batching of > notifications to be important, whether we'd want to embedd it into the > protocol, so that an event notification response could return 1 to N > notifications in a single message. This would be more optimal and should not > result in a huge message since values will not be sent over, only keys if > anything. > > Otherwise, batching of notifications could be implemented at a later stage > using a similar method to the replication queue. We could even consider using > disruptor instead of a blocking queue… Lets start without batching then, at least for a first pass. Cheers Manik -- Manik Surtani [email protected] twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
