Thanks Pavel, Salava... I guess it boils down to a lack of an "exactly-once" processing guarantee when more than one cache is involved.
We can maybe solve this problem for our smaller caches by combining them into one single cache... that way, all data is contained within the MutableEntry which gets reset to its original state for the second execution. Some of our caches have small values and we can use this approach. But some caches further downstream have large values and churn frequently, so combining them may be less viable. It would be nice if we could have a configuration option or an API overload for bubbling up exceptional scenarios (connection errors, rebalancing, binary registration) to the application so the application could handle retries itself - and thus, treat retries differently than the initial attempt. That way, the application can use the "short circuit if nothing changed" path for the 99% of cases where the entry processor only executed once, and then the "repropagate everything downstream even if nothing changed" path for the exceptional cases where the entry processor may have executed twice. This would save us a lot of processing. If we have that in Ignite 3, we may even be able to get close to "exactly-once" by starting a transaction on the client, using that transaction id in a ComputeJob, and then if an exception is bubbled back to the client, the client can roll back the transaction and start a new one for its retry. On Fri, Jul 12, 2024 at 5:54 AM Pavel Tupitsyn <[email protected]> wrote: > > how did you discover the answer to this > > By enabling "break on all exceptions" in my IDE. > This exception is not logged, Ignite considers this a normal situation, > registers the type automatically and then re-runs the processor. > > As Slava said, you should not rely on the fact that the processor will be > executed only once, automated retries are possible in different situations > (connection errors, rebalance, etc). >
