Hi,

On 09/09/15 17:39, "Marcel Reutegger" <[email protected]> wrote:

>>* as pointed out by MichaelD they could have a backlog yet to process
>>towards the old store - which they cannot access anymore as that one
>>would
>>be forcibly closed
>
>in my view, those observers should be unregistered from the store before
>it is shut down and any backlog cleared, i.e. it will be lost.

yes they do get unregistered right away indeed - but atm there's no handle
as to prevent eg the BackgroundObserver from still having entries in the
queue and continuing to process them. so those queued entries will indeed
fail as the store is closed.

>>* there is not yet a proper way to switch from old to new ('reset') - esp
>>is there a risk that there could be a gap (this part we might be able to
>>fix though, not sure)
>
>I don't see a requirement for this. if you restart the entire stack you
>will also have a gap.

the difference is perhaps that if you restart the stack this is done as an
explicit admin operation, knowingly. While as what we're trying to achieve
here is something automated, 'under the hood', which has a different
quality requirement imv.

>>* both above carry the risk that Observers miss some changes - something
>>which would be unacceptable I guess.
>
>same as above. I don't think observers must survive a node store restart.
>I even think it is wrong. Every client of the node store should be
>restarted in that case, including Observers.

I think if the observers would all be 'OSGi-ified' then this could be
achieved. But currently eg the BackgroundObserver is just a pojo and not
an osgi component (thus doesn't support any activate/deactivate method
hooks).

Cheers,
Stefan


Reply via email to