On Thu, Feb 23, 2012 at 7:37 PM, Galder Zamarreño <[email protected]> wrote: > > On Feb 22, 2012, at 5:26 PM, Galder Zamarreño wrote: > >> >> On Feb 22, 2012, at 1:00 PM, Manik Surtani wrote: >> >>> >>> 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. >> >> Hmmm, not sure that could work. It's the client that knows whether two >> channels belong to the same client (i.e. two channels generated by same >> remote cache manager for example). >> >> So, I'm inclined to think that such ID should be generated by the client >> itself. If you wanna avoid sending it with each request, you'd have to >> assume that there's a first-request where that info comes, and assume that >> for the rest of the time the channel is open, that won't change. This is a >> fair assumption but complicates clients cos they need to differentiated >> between the first and any subsequent requests. >> >> I'm investigating other possibilities. > > Btw, I'm reading > http://sigops.org/sosp/sosp11/current/2011-Cascais/10-adya-online.pdf which > talks about Google's Thialfi client notification service and they have a > similar mechanism. > > "When present, the optional source parameter identifies the client that made > the change. (This ID is provided by the application client at startup and is > referred to as its application ID.) As an optimization, Thialfi omits > delivery of the notification to this client, since the client already knows > about the change." > > So, they go for the option of providing this logical ID on startup and then > be able to avoid sending the notification to the originating node. > > I think we could add this app or logica id as part of the add/register > listener call and avoid sending it with all operations. Tbh, only those nodes > that have register a listener care about knowing the event was generated > locally or not, and only those care about not receiving notifications in all > their channels. > > So, I think this could work.
You could send the client id only with ping requests and force the client to send a ping request when it first connects to the server. (I think it already does.) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
