[infinispan-dev] Remote Hot Rod events wiki updated

[Radim Vansa]

On 04/22/2014 03:58 PM, Dan Berindei wrote:
> On Tue, Apr 22, 2014 at 2:30 PM, Galder Zamarreño <galder at redhat.com> 
> wrote:
>> On 17 Apr 2014, at 08:03, Radim Vansa <rvansa at redhat.com> wrote:
>>
>>     On 04/16/2014 05:38 PM, William Burns wrote:
>>
>>         On Wed, Apr 16, 2014 at 11:14 AM, Galder Zamarreño
>>         <galder at redhat.com> wrote:
>>
>>             On 11 Apr 2014, at 15:25, Radim Vansa <rvansa at redhat.com>
>>             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
>

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...)

Radim

-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140422/1f3f8ba3/attachment.html