[infinispan-issues] [JBoss JIRA] (ISPN-4720) Values data reverts in Compatibilty mode in Infinispan 6.0.2

[Prashant Thakur (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002040#comment-13002040 ] 

Prashant Thakur edited comment on ISPN-4720 at 9/12/14 3:10 PM:
----------------------------------------------------------------

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 data 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.



was (Author: prashant.thakur):
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)