If all that is true, we would need a reproducer to debug this issue further.
Or, if you manage to stall a system in a failed state, you can debug the flow which reads an invalid version. From your description, you should see that get() from replicated cache reads the version locally and during commit it compares it with the different version. The culprit is that either one of the steps is non-local, or one of the versions being read and verified somehow are taken from different sources. пт, 28 февр. 2020 г. в 15:03, Prasad Bhalerao <prasadbhalerao1...@gmail.com >: > Hi, > > My all tasks are affinity tasks, so they are always submitted to primary > node. How setting DIGNITE_READ_LOAD_BALANCING to false help in this case ? > Even if it is true it will always read the values from primary node as the > task is landed on primary node. > > Thanks, > Prasad > > On Fri, Feb 28, 2020 at 4:45 PM Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > >> Prasad, >> >> The current version in the entry is checked agains the version which was >> read from the very same entry, so with absence of concurrent updates the >> version will be the same. >> >> From your description, I think there might be a concurrent read for the >> key that you clear which loads the value on primary node with a different >> version. Then, the read happening inside transaction always reads the value >> from backup which leads to a permanent version mismatch; I reproduced this >> scenario locally. The -DIGNITE_READ_LOAD_BALANCING=false fixes the issue at >> a price of disabling read load balancing. >> >> I will create a ticket for the issue shortly, perhaps someone from the >> community will pick it up. >> >
