On 02/09/16 13:41, "Stefan Egli" <[email protected]> wrote:
>On 02/09/16 13:26, "Chetan Mehrotra" <[email protected]> wrote: > >>Listener for local Change >>---------------------------------- >> >>Such a listener is more particular about type of change and is doing >>some persisted state change i.e. like registering a job, invoking some >>third party service to update the value. This listener is only >>interested in local as it know same listener is also active on other >>cluster node (homogeneous cluster setup) so if a node gets added it >>only need to react on the cluster node where it got added. > >One thing this reminds me of is a use-case where you have say 3 cluster >nodes, each one handling mainly local events lets say. All fine. Then 1 >node crashes while likely it's (local) observation queue wasn't entirely >empty. Those events would then probably not get handled by anyone (and >that node wouldn't necessarily be restarted as the cluster continues >normally, it could be restarted as a new clusterNodeId..). So maybe >there's an issue there. I think this should be handled same as today with (non-journaled) listeners loosing events on any crash: either upon restart or when an instance leaves the cluster (which can be noticed eg via Sling's Discovery API) someone (preferably the leader) should handle this and do a repository scan of whatever interesting the crashing instance might have stored. Lack of journaled observation that's the way to go probably. Cheers, Stefan
