[infinispan-issues] [JBoss JIRA] (ISPN-4720) Values data reverts in Compatibilty mode in Infinispan 6.0.2
[
https://issues.jboss.org/browse/ISPN-4720?page=com.atlassian.jira.plugin....
]
Prashant Thakur updated ISPN-4720:
----------------------------------
Attachment: distributed_cache_configuration.xml
tc2.out
tc3.out
tc4.out
tc1.zip
Attaching complete logs and configuration of 4 nodes.
Please note that tc1 is the co-ordinator, we are storing Subscriber Balance data tracked
in real time using Infinispan.
There are two caches SubscriberBalance and SubscriberBalance_ChangeLog.
First being the main storage and second an implementation in replication mode which id of
main cache and version information.
An Asyc DB Writer thread keeps track of flushing the daa into the database based on a
flush size configured. Since we dont want to lose any data we have gone ahead with this
approach rather than Inifinispan's Async approach of writes to persistent store where
we can always lose X amount of data when the node goes down.
Please have a look at transitions happening at id=1029 at tc1 . In this case the
transaction was initiated at tc2 i.e Node 2 and then its transferred to Node 1.
Node 1 then again reverts back to Old value.
Please let me know in case you require further details.
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
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)