<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/22/2014 03:58 PM, Dan Berindei
wrote:<br>
</div>
<blockquote cite="mid:1398175132.28062.3@smtp.gmail.com" type="cite">On
Tue, Apr 22, 2014 at 2:30 PM, Galder Zamarreño
<a class="moz-txt-link-rfc2396E" href="mailto:galder@redhat.com"><galder@redhat.com></a> wrote:<br>
<blockquote type="cite">
<div class="plaintext" style="white-space: pre-wrap;">
On 17 Apr 2014, at 08:03, Radim Vansa
<a class="moz-txt-link-rfc2396E" href="mailto:rvansa@redhat.com"><rvansa@redhat.com></a> wrote:
<blockquote> On 04/16/2014 05:38 PM, William Burns wrote:
<blockquote> On Wed, Apr 16, 2014 at 11:14 AM, Galder
Zamarreño <a class="moz-txt-link-rfc2396E" href="mailto:galder@redhat.com"><galder@redhat.com></a> wrote:
<blockquote> On 11 Apr 2014, at 15:25, Radim Vansa
<a class="moz-txt-link-rfc2396E" href="mailto:rvansa@redhat.com"><rvansa@redhat.com></a> wrote:
<blockquote> OK, now I get the picture. Every time we
register to a node (whether the first time or after
previous node crash), we receive all (filtered) keys
from the whole cache, along with versions. Optionally
values as well.
</blockquote>
Exactly.
<blockquote> In case that multiple modifications happen
in the time window before registering to the new
cache, we don't get the notification for them, just
again the whole cache and it's up to application to
decide whether there was no modification or some
modifications.
</blockquote>
I’m yet to decide on the type of event exactly here,
whether cache entry created, cache entry modified or a
different one, but regardless, you’d get the key and the
server side version associated with that key. A user
provided client listener implementation could detect
which keys’ versions have changed and react to that,
i.e. lazily fetch new values. One such user provided
client listener implementation could be a listener that
maintains a near cache for example.
</blockquote>
My current code was planning on raising a
CacheEntryCreatedEvent in this case. I didn't see any
special reason to require a new event type, unless anyone
can think of a use case?
</blockquote>
When the code cannot rely on the fact that created = (null
-> some) and modified = (some -> some), it seems to me
that the user will have to handle the events in the same
way. I don't see the reason to differentiate between them in
protocol anyway. One problem that has come to my mind: what
about removed entries? If you push the keyset to the client,
without marking start and end of these events (and expecting
the client to fire removed events for all not mentioned keys
internally), the client can miss some entry deletion
forever. Are the tombstones planned for any particular
version of Infinispan?
</blockquote>
That’s a good reason why a different event type might be
useful. By receiving a special cache entry event when keys are
being looped, it can detect that a keyset is being returned,
for example, if the server went down and the Hot Rod client
transparently failed over to a different node and re-added the
client listener. The user of the client, say a near cache,
when it receives the first of this special event, it can make
a decision to say, clear the near cache contents, since it
might have missed some events.
The different event type gets around the need for a start/end
event. The first time the special event is received, that’s
your start, and when you receive something other than the
special event, that’s the end, and normal operation is back in
place.
WDYT?</div>
</blockquote>
<div><br>
</div>
<div>I'm not sure if you plan multi-threaded event delivery in the
Java client, but having a special start event would make it
clear that it must be delivered after all the events from the
old server and before any events from the new server.</div>
<div><br>
</div>
<div>And it should also make special cases like a server dying
before it finished sending the initial state easier to handle.</div>
<div><br>
</div>
<div>Dan</div>
<div><br>
</div>
</blockquote>
<br>
Is it really wise to have stateful listener? I would prefer the
listener to be called only once per server change, and let it
iterate the cache via cache.forEach(ForEachTask task), or
cache.iterator(). (which would replace the keySet() etc...)<br>
<br>
Radim<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>