]
Dan Berindei commented on ISPN-4720:
------------------------------------
Looks like the problem is caused by a concurrent activation from the cache store:
remote-thread-0: receive PrepareCommand(gtx, ReplaceCommand(key, oldValue, newValue))
remote-thread-0: the key doesn't exist in the data container, read the old value from
the store
remote-thread-0: send PrepareCommand response
OOB-2: receive ClusteredGet(key)
OOB-2: the key still doesn't exist in the data container, read the old value from the
store and set the isLoaded flag
remote-thread-0: receive CommitCommand(gtx)
remote-thread-0: commit key=newValue to the data container and the store
remote-thread-0: send CommitCommand response
OOB-2: commit key=oldValue to the data container because of the isLoaded flag
This has already been fixed on the 7.0 stream since 7.0.0.Alpha3, with ISPN-3797.
Values data reverts in Compatibilty mode in Infinispan 6.0.2
------------------------------------------------------------
Key: ISPN-4720
URL:
https://issues.jboss.org/browse/ISPN-4720
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 6.0.2.Final
Environment: Linux 3.15.8-200.fc20.x86_64
Reporter: Prashant Thakur
Assignee: Dan Berindei
Priority: Critical
Labels: Infinispan
Attachments: distributed_cache_configuration.xml, tc1.zip, tc2.out, tc3.out,
tc4.out
1) The owners of the keys are Node1 and Node4
0911 10:56:56,552 TRACE
[org.infinispan.interceptors.distribution.TxDistributionInterceptor] [remote-thread-0]
(TxDistributionInterceptor.java:362) - Not doing a remote get for key 1029 since entry is
mapped to current node (blrsrv42-19390), or is in L1. Owners are [blrsrv29-4565,
blrsrv42-19390]
2. The request for update came to Node2 a non-owner.
0911 10:56:56,388 TRACE [org.infinispan.statetransfer.StateTransferInterceptor]
[HotRodServerWorker-2] (StateTransferInterceptor.java:203) - handleNonTxWriteCommand for
command ReplaceCommand{key=1029, oldValue=TestData{id=1029, field1=XXXXXX},
newValue=TestData{id=1029, field1=cyyy},
metadata=EmbeddedMetadata{version=NumericVersion{version=844433520066561}},
flags=[OPERATION_HOTROD], successful=true, valueMatcher=MATCH_EXPECTED}
3. The updates are happening in Node1 and overwritten again with old data present in OOB
Thread. Because of which the Node1, reverts back to the old data.
4. While doing a get from Node 1 we again receive the old value