[infinispan-dev] Remote Hot Rod events wiki updated
Radim Vansa
rvansa at redhat.com
Tue Apr 22 11:19:34 EDT 2014
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
More information about the infinispan-dev
mailing list