Observe callback called twice

Hello All,

I’m encountering a strange behaviour using Actyx Pond. Sometimes a single emitted event for a fish “generates” 2 calls of the corresponding observe callback function, sometime with 8 minutes delays ! I’ve validated this behaviour by checking the events list thanks to AQL and by adding logs in the observe callback function. For the observer code I’m using RxPond, ActyxOS is at version 2.6.1 (we moved to 2.8.1 few hours ago) and Pond version is 3.0.2.

Did anyone encountered such a behaviour ? I know that sometime there are some network outage, do you know if it can cause an observe callback function to be called twice ?

Thanks a lot,

Sébastien

Hi Sébastien,

yes, new events from the network may trigger the callback even when the state doesn’t change. If you don’t want these, you should be able to suppress them with RxJS’s distinctUntilChanged combinator.

Regards,

Roland

Thank you Roland, it was also my conclusion. Do you think it can be a kind of best practice, a golden rule, when using RxJs to observe states ?

Thanks,

Sébastien

Your question makes me cautious: our system guarantees only state, not triggers. Even if you deduplicate “equal” updates, this doesn’t give you a guarantee like “I will see every update only once” — consider for example an app restart. So my recommendation is instead to explicitly record the actions you have taken in response to seeing the updates you are interested in, by emitting additional events. This allows you to continue your processing across all sorts of outages and interruptions and leads to a resilient system.

In general, this works like the following: you observe a certain fish state in one place which tells you that something needs to be changed elsewhere, so you make that change (possibly checking that it hasn’t yet been done) and then emit another event for your observed fish to record that the change has been propagated. With this working principle you can think through the process, assuming a possible hardware failure at any point in time, and see how after failure recovery the system will eventually end up in the state you want. The Actyx tools that make this possible are durable event storage and reliable event communication — if you use a SQL DB that database and its replication mechanism play the same role and your queries correspond to the fish logic.

Ok I understand. Thank you for explanation.

Sébastien