On 12/06/2013 08:52 AM, Mircea Markus wrote: > Some notes: > > "This means that the Hot Rod protocol will be extended so that operation > headers always carry a Source ID field." > - shall we add a new intelligence level to handle this? Besides reducing the > payload, would allow upgrading the java and Cpp clients independently.
Instead of a new intelligence level, if the client told the server what features it supports when connecting this could be done more fine-grained, so that a client could support some subset of functionality (instead of being forced to implement the specific extentions in one of the pre-defined intelligence levels). -Dennis > In one of our discussions, you've also mentioned that you'd want to use the > cluster listeners as a foundation for this functionality. That doesn't seem > to be the case from the document, or? Not that it's a bad thing, just that I > want to clarify the relation between the two. Another way to handle > connection management, based on clustered listeners, would be: > - the node on which the listeners ID hashes is the only one responsible for > piggyback notifications to the remote client > - it creates a cluster listener to be notified on what to send to the client > (can make use cluster listener's filtering and transformer capabilities here) > > Comparing the two approaches: this approach reuses some code (not sure how > much, we might be able to do that anyway) from the cluster listeners and also > reduces the number of connections required between clint and server, but at > the cost of performance/network hops. Also the number of connections a client > is required to have hasn't been a problem yet. > > One more note on ST: during ST a node might receive the same notification > multiple times (from old owner and new owner). I guess it makes sense > documenting that? > > On Dec 5, 2013, at 4:16 PM, Galder Zamarreño <gal...@redhat.com> wrote: > >> Hi all, >> >> Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events >> >> Thanks a lot for the feedback provided in last thread. It was very >> constructive feedback :) >> >> I've just finished updating the design document with the feedback provided >> in the previous email thread. Can you please have another read and let the >> list know what you think of it? >> >> Side note: The scope has got bigger (with the addition of >> filters/converters), so we might need to consider whether we want all >> features in next version, or whether some parts could be branched out to >> next iterations. > +1. Can we include the notification ack in the optionals category? > What about leaving these as the last bit to be implemented? If time allows > (not to delay the release) we can add them, otherwise just add them in future > iterations? > > >> Cheers, >> -- >> Galder Zamarreño >> gal...@redhat.com >> twitter.com/galderz >> >> Project Lead, Escalante >> http://escalante.io >> >> Engineer, Infinispan >> http://infinispan.org >> > Cheers, _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
