[infinispan-dev] Remote Hot Rod events wiki updated

[Galder Zamarreño]

On 22 Apr 2014, at 17:19, Radim Vansa <rvansa at redhat.com> wrote:

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

That might be an option in the future, but it needs that kind of remote iterator operation to be implemented on top of HotRod. For 7.0, we’ll go with receiving events.

> 
> Radim
> 
> -- 
> Radim Vansa 
> <rvansa at redhat.com>
> 
> JBoss DataGrid QA
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Galder Zamarreño
galder at redhat.com
twitter.com/galderz