<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi,<br>
<br>
I still don't think that the document covers properly the
description of failover.<br>
<br>
My understanding is that client registers clustered listeners on
one server (the first one it connects, I guess). There's some
space for optimization, as the notification will be sent from
primary owner to this node and only then over hotrod to the
client, but I don't want to discuss it now.<br>
<br>
> Listener registrations will survive node failures thanks to
the underlying clustered listener implementation.<br>
<br>
I am not that much into clustered listeners yet, but I think that
the mechanism makes sure that when the primary owner changes, the
new owner will then send the events. But when the node which
registered the clustered listener dies, others will just forgot
about it.<br>
<div>
</div>
<div>
<p>> When a client detects that the server which was serving
the events is gone, it needs to resend it’s registration to
one of the nodes in the cluster. Whoever receives that request
will again loop through its contents and send an event for
each entry to the client.<br>
</p>
<p>Will that be all entries in the whole cache, or just from
some node? I guess that the first is correct. So, as soon as
one node dies, all clients will be bombarded by the full cache
content (ok, filtered). Even if these entries have not
changed, because the cluster can't know. </p>
<p>> This way the client avoids loosing events. Once all
entries have been iterated over, on-going events will be sent
to the client.</p>
</div>
<div>
<p>> This way of handling failure means that clients will
receive <em>at-least-once</em> delivery of cache updates. It
might receive multiple events for the cache update as a result
of topology changes handling.<br>
</p>
<p>So, if there are several modifications before the client
reconnects and the new target registers the listener, the
clients will get only notification about the last
modification, or rather just the entry content, right?<br>
</p>
<p>Radim<br>
</p>
</div>
<br>
On 04/02/2014 01:14 PM, Galder Zamarreño wrote:<br>
</div>
<blockquote
cite="mid:18D41294-AB90-4119-9E85-BECEAFBA8E38@redhat.com"
type="cite">
<pre wrap="">Hi all,
I’ve finally managed to get around to updating the remote hot rod event design wiki [1].
The biggest changes are related to piggybacking on the cluster listeners functionality in order to for registration/deregistration of listeners and handling failure scenarios. This should simplify the actual implementation on the Hot Rod side.
Based on feedback, I’ve also changed some of the class names so that it’s clearer what’s client side and what’s server side.
A very important change is the fact that source id information has gone. This is primarily because near-cache like implementations cannot make assumptions on what to store in the near caches when the client invokes operations. Such implementations need to act purely on the events received.
Finally, a filter/converter plugging mechanism will be done via factory implementations, which provide more flexibility on the way filter/converter instances are created. This opens the possibility for filter/converter factory parameters to be added to the protocol and passed, after unmarshalling, to the factory callbacks (this is not included right now).
I hope to get started on this in the next few days, so feedback at this point is crucial to get a solid first release.
Cheers,
[1] <a class="moz-txt-link-freetext" href="https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events">https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events</a>
--
Galder Zamarreño
<a class="moz-txt-link-abbreviated" href="mailto:galder@redhat.com">galder@redhat.com</a>
twitter.com/galderz
Project Lead, Escalante
<a class="moz-txt-link-freetext" href="http://escalante.io">http://escalante.io</a>
Engineer, Infinispan
<a class="moz-txt-link-freetext" href="http://infinispan.org">http://infinispan.org</a>
_______________________________________________
infinispan-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Radim Vansa <a class="moz-txt-link-rfc2396E" href="mailto:rvansa@redhat.com"><rvansa@redhat.com></a>
JBoss DataGrid QA
</pre>
</body>
</html>