Skip to content

IGNITE-29292 Keep the backups consistent when the class registration on retry of an ATOMIC update fails - #13830

Draft
rezataroosheh wants to merge 1 commit into
apache:masterfrom
rezataroosheh:IGNITE-29292
Draft

rezataroosheh wants to merge 1 commit into
apache:masterfrom
rezataroosheh:IGNITE-29292

Conversation

@rezataroosheh

Copy link
Copy Markdown
Contributor

JIRA: https://issues.apache.org/jira/browse/IGNITE-29292

Status

Draft. For now this PR only adds a test that reproduces the problem on master. The fix will follow.

Problem

GridDhtAtomicCache.updateAllAsyncInternal0() catches UnregisteredClassException from update(), registers the class with BinaryContext.registerType(), and retries the update from dhtUpdRes.processedEntriesCount(). The keys before that index are already written on the primary, and their DHT update waits in dhtUpdRes.dhtFuture() to be sent to the backups after the retry.

If registerType() fails (for example, because the thread is interrupted), the error goes to the catch (Throwable) block. It logs "Unexpected exception during cache update", fails all keys of the request, and returns before the DHT future is mapped. So the keys already written on the primary never reach the backups.

Test

AtomicUpdateRetryInterruptTest (added to IgniteCacheTestSuite7) starts two server nodes with an ATOMIC cache with one backup. A discovery hook holds back the class name registration. On an interrupted thread, it runs invokeAll on two keys of node 0: the entry processor sets 1 for the first key and a value of a new class for the second key. The test checks that the primary and the backup have the same value of the first key.

Result on master: the test fails with
The backup has a different value of the first key [primary=1, backup=null].
The log shows "Unexpected exception during cache update" with BinaryObjectException: Failed to register class from BinaryContext.registerType(), called from updateAllAsyncInternal0(), caused by IgniteInterruptedCheckedException.

The Contribution Checklist

  • There is a single JIRA ticket related to the pull request.
  • The web-link to the pull request is attached to the JIRA ticket.
  • The JIRA ticket has the Patch Available state.
  • The pull request body describes changes that have been made.
    The description explains WHAT and WHY was made instead of HOW.
  • The pull request title is treated as the final commit message.
    The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
  • A reviewer has been mentioned through the JIRA comments
    (see the Maintainers list)
  • The pull request has been checked by the Teamcity Bot and
    the green visa attached to the JIRA ticket (see tab PR Check at TC.Bot - Instance 1 or TC.Bot - Instance 2)

… after the class registration on retry fails
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant