On 12/06/2013 03:52 PM, 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.
Is a new intelligence
level required? Protocol 1.4 should specify a bit
flag "carrying SourceID/not carrying SourceID". If the client is dumb,
it simply leaves the flag to default and as it won't register any
listener, the server wont bother him with any new information. If it
starts registering listeners, the server should start sending events. We
may speak about it as L4, if you wish, but there's no need to add new
intelligence level to the protocol.
Btw., when Hot Rod fails to hit the primary owner, should the non-owner
propagate the SourceID to primary owner somehow? Or is in this case
acceptable notifying the listener about its own change?
Radim
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 <galder(a)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
> galder(a)redhat.com
>
twitter.com/galderz
>
> Project Lead, Escalante
>
http://escalante.io
>
> Engineer, Infinispan
>
http://infinispan.org
>
Cheers,
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA