Reza Taroosheh created IGNITE-29291:
---------------------------------------

             Summary: ATOMIC invokeAll with a write-through store puts wrong 
values into the near cache when a key is left unchanged
                 Key: IGNITE-29291
                 URL: https://issues.apache.org/jira/browse/IGNITE-29291
             Project: Ignite
          Issue Type: Bug
            Reporter: Reza Taroosheh
            Assignee: Reza Taroosheh
             Fix For: 2.20


GridDhtAtomicCache.updateWithBatch() collects the entries to write in the list 
"filtered" and passes
"firstEntryIdx" to updatePartialBatch(). updatePartialBatch() uses 
"firstEntryIdx + i" as the request
index of the i-th entry of the batch. This is right only if the batch has no 
gaps.

A key is skipped without being added to the batch when:
- the entry processor does not modify the entry (read-only invoke);
- the new value fails validation;
- the interceptor cancels the update.

"firstEntryIdx" is advanced only for a key rejected by the filter, and that is 
right only if no key was
added to the batch before it. Also, after a retry on UnregisteredClassException 
or
UnregisteredBinaryTypeException, the loop starts at 
dhtUpdRes.processedEntriesCount(), but
"firstEntryIdx" starts at 0.

The wrong index is used for res.addNearValue(), res.addNearTtl(), 
res.addSkippedIndex() and
dhtUpdRes.processedEntriesCount().

updateWithBatch() is used for requests with more than one key on a cache with a 
write-through store
that is not local.

Reproducer:
One server, one client with a near cache, ATOMIC cache with a write-through 
store. The client puts keys
1, 2 and 3, then calls invokeAll on them. The entry processor sets each value 
to its key, but leaves key 2
unchanged.

Expected: the client's near cache has 1, the old value, and 3.
Actual:
- the near cache of the client has value 3 for key 2;
- the client fails with an AssertionError in 
GridNearAtomicCache.processNearAtomicUpdateResponse()
  ("assert req.operation() != TRANSFORM"), because index 2 has neither a near 
value nor a skipped index.
  The failure handler is called with CRITICAL_ERROR.




--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to