[IGNITE-16621] AtomicSequence.incrementAndGet() fails intermittently.

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.13
• Component/s: data structures
• Labels: ise
• Release Note: Fixed an issue with IgniteAtomicSequence that led to AssertionError.
• Ignite Flags: Release Notes Required
• Assignee: Vyacheslav Koptilin
• Reporter: Vyacheslav Koptilin
• Reviewer: Vladislav Pyatkov
• Created: 22/Feb/22 16:29
• Updated: 01/Nov/22 11:31
• Resolved: 27/Feb/22 18:48

Description

Using IgniteAtomicSequence can lead to the following AssertionError:

java.lang.AssertionError: null
at org.apache.ignite.internal.processors.datastructures.GridCacheAtomicSequenceImpl$2.call(GridCacheAtomicSequenceImpl.java:307)
at org.apache.ignite.internal.processors.datastructures.GridCacheAtomicSequenceImpl$2.call(GridCacheAtomicSequenceImpl.java:298)
at org.apache.ignite.internal.processors.cache.GridCacheUtils.retryTopologySafe(GridCacheUtils.java:1418)
at org.apache.ignite.internal.processors.datastructures.GridCacheAtomicSequenceImpl.internalUpdate(GridCacheAtomicSequenceImpl.java:230)
at org.apache.ignite.internal.processors.datastructures.GridCacheAtomicSequenceImpl.incrementAndGet(GridCacheAtomicSequenceImpl.java:135)

The following code produces the mentioned error:

private Callable<Long> internalUpdate(final long l, final boolean updated) {
    return new Callable<Long>() {
        @Override public Long call() throws Exception {
            assert distUpdateFreeTop.isHeldByCurrentThread() || distUpdateLockedTop.isHeldByCurrentThread();

            try (GridNearTxLocal tx = CU.txStartInternal(ctx, cacheView, PESSIMISTIC, REPEATABLE_READ)) {
                GridCacheAtomicSequenceValue seq = cacheView.get(key);

                checkRemoved();

                assert seq != null; <-- This assert can trigger the error in case the partition loss policy is IGNORE and the corresponding partition has been lost.

The root cause of the issue is that for in-memory case partition loss policy is IGNORE. Therefore, the following read can return a null value without any exceptions and trigger the mentioned AssertionError.

try (GridNearTxLocal tx = CU.txStartInternal(ctx, cacheView, PESSIMISTIC, REPEATABLE_READ)) {
    GridCacheAtomicSequenceValue seq = cacheView.get(key);

The possible workaround is setting a reasonable number of backups in AtomicConfiguration. Monitoring of lost partitions would be nice as well.

The proposed solution is quite obvious. Need to change the assert assert seq != null; to explicit check and throw a suitable exception if needed. This should allow the user to detect this and re-create the sequence, for example.

Issue Links

• links to: GitHub Pull Request #9847