Re: [infinispan-dev] Remote Hot Rod events wiki updated

On Tue, Apr 22, 2014 at 2:30 PM, Galder Zamarreño <galder(a)redhat.com&gt; wrote: > On 17 Apr 2014, at 08:03, Radim Vansa <rvansa(a)redhat.com&gt; wrote: > > On 04/16/2014 05:38 PM, William Burns wrote: > > On Wed, Apr 16, 2014 at 11:14 AM, Galder Zamarreño > <galder(a)redhat.com&gt; wrote: > > On 11 Apr 2014, at 15:25, Radim Vansa <rvansa(a)redhat.com&gt; > wrote: > > 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. > > Exactly. > > 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. > > 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. > > 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? > > 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? > > 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? 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. And it should also make special cases like a server dying before it finished sending the initial state easier to handle. Dan