On 11 Apr 2014, at 15:25, Radim Vansa <[email protected]> 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. > As the version for > entries is incremented per cache and not per value, there is no way to > find out how many times the entry was modified (we can just know it was > modified when we remember the previous version and these versions differ). Exaclty, the only assumption you can make is that the version it’s different, and that’s it’s a newer version that the older one. > Thanks for the clarifications, Galder - I was not completely sure about > this from the design doc. No probs > Btw., could you address Dan's question: > > "Don't we want to allow the user to pass some data to the filter factory > on registration? > Otherwise we'd force the user to write a separate filter factory class > every time they want to track changes to a single key." > > I know this was already asked several times, but the discussion has > always dissolved. I haven't seen the final "NO”. > > Radim > > On 04/11/2014 02:36 PM, Galder Zamarreño wrote: >> On 04 Apr 2014, at 19:11, William Burns <[email protected]> wrote: >> >>> On Fri, Apr 4, 2014 at 3:29 AM, Radim Vansa <[email protected]> wrote: >>>> Hi, >>>> >>>> I still don't think that the document covers properly the description of >>>> failover. >>>> >>>> My understanding is that client registers clustered listeners on one server >>>> (the first one it connects, I guess). There's some space for optimization, >>>> as the notification will be sent from primary owner to this node and only >>>> then over hotrod to the client, but I don't want to discuss it now. >>> There could be optimizations, but we have to worry about reordering if >>> the primary owner doesn't do the forwarding. You could have the case >>> of multiple writes to the same key from the clients and lets say they >>> send the message to the listener after they are written to the cache, >>> there is no way to make sure they are done in the order they were >>> written to the cache. We could do something with versions for this >>> though. >> Versions do not provide global ordering. They are used, at each node, to >> identify an update, so they’re incrementing at the node level, mixed with >> some other data that’s node specific to make them unique cluster wide. >> However, you can’t assume global ordering based on those with the current >> implementation. I agree there’s room for optimizations but I think >> correctness and ordering are more important right now. >> >>>>> Listener registrations will survive node failures thanks to the underlying >>>>> clustered listener implementation. >>>> I am not that much into clustered listeners yet, but I think that the >>>> mechanism makes sure that when the primary owner changes, the new owner >>>> will >>>> then send the events. But when the node which registered the clustered >>>> listener dies, others will just forgot about it. >>> That is how it is, I assume Galder was referring to node failures not >>> on the one that registered the listener, which is obviously talked >>> about in the next point. >> That’s correct. >> >>>>> When a client detects that the server which was serving the events is >>>>> gone, it needs to resend it's registration to one of the nodes in the >>>>> cluster. Whoever receives that request will again loop through its >>>>> contents >>>>> and send an event for each entry to the client. >>>> Will that be all entries in the whole cache, or just from some node? I >>>> guess >>>> that the first is correct. So, as soon as one node dies, all clients will >>>> be >>>> bombarded by the full cache content (ok, filtered). Even if these entries >>>> have not changed, because the cluster can't know. >>> The former being that the entire filtered/converted contents will be sent >>> over. >> Indeed the former, but the entire entry, only keys, and latest versions, >> will be sent by default. Converters can be used to send value side too. >> >>>>> This way the client avoids loosing events. Once all entries have been >>>>> iterated over, on-going events will be sent to the client. >>>>> This way of handling failure means that clients will receive at-least-once >>>>> delivery of cache updates. It might receive multiple events for the cache >>>>> update as a result of topology changes handling. >>>> So, if there are several modifications before the client reconnects and the >>>> new target registers the listener, the clients will get only notification >>>> about the last modification, or rather just the entry content, right? >> @Radim, you don’t get the content by default. You only get the key and the >> last version number. If the client wants, it can retrieve the value too, or >> using a custom converter, it can send back the value, but this is optional. >> >>> This is all handled by the embedded cluster listeners though. But the >>> end goal is you will only receive 1 event if the modification comes >>> before value was retrieved from the remote node or 2 if afterwards. >>> Also these modifications are queued by key and so if you had multiple >>> modifications before it retrieved the value it would only give you the >>> last one. >>> >>>> Radim >>>> >>>> >>>> On 04/02/2014 01:14 PM, Galder Zamarreño wrote: >>>> >>>> Hi all, >>>> >>>> I've finally managed to get around to updating the remote hot rod event >>>> design wiki [1]. >>>> >>>> The biggest changes are related to piggybacking on the cluster listeners >>>> functionality in order to for registration/deregistration of listeners and >>>> handling failure scenarios. This should simplify the actual implementation >>>> on the Hot Rod side. >>>> >>>> Based on feedback, I've also changed some of the class names so that it's >>>> clearer what's client side and what's server side. >>>> >>>> A very important change is the fact that source id information has gone. >>>> This is primarily because near-cache like implementations cannot make >>>> assumptions on what to store in the near caches when the client invokes >>>> operations. Such implementations need to act purely on the events received. >>>> >>>> Finally, a filter/converter plugging mechanism will be done via factory >>>> implementations, which provide more flexibility on the way filter/converter >>>> instances are created. This opens the possibility for filter/converter >>>> factory parameters to be added to the protocol and passed, after >>>> unmarshalling, to the factory callbacks (this is not included right now). >>>> >>>> I hope to get started on this in the next few days, so feedback at this >>>> point is crucial to get a solid first release. >>>> >>>> Cheers, >>>> >>>> [1] https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events >>>> -- >>>> Galder Zamarreño >>>> [email protected] >>>> twitter.com/galderz >>>> >>>> Project Lead, Escalante >>>> http://escalante.io >>>> >>>> Engineer, Infinispan >>>> http://infinispan.org >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>>> >>>> >>>> -- >>>> Radim Vansa <[email protected]> >>>> JBoss DataGrid QA >>>> >>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Galder Zamarreño >> [email protected] >> twitter.com/galderz >> >> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > -- > Radim Vansa <[email protected]> > JBoss DataGrid QA > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño [email protected] twitter.com/galderz _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
