[infinispan-issues] [JBoss JIRA] (ISPN-2974) DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled

[Paul Ferraro (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reopened ISPN-2974:
--------------------------------



This issue is still present in 5.2.6.Final, although the conditions might be different.
See: https://bugzilla.redhat.com/show_bug.cgi?id=900549

In summary, we're using a Cache<String, AtomicMap<Byte, Object>>.  The issue appears during continuous load following server restart, upon which the cache store entries are purged (purgeOnStartup=true) and fetched from a remote node (fetchPersistentState=true).  The NPE is due to a missing atomic map entry, which should always exist, as it is always put there on the same request that created the cache entry.

The failing test has 4 nodes, the cache uses REPL_SYNC, a batch-mode tx manager, all cache access happens within the context of a batch, pessimistic locking, always performs a Cache.lock(...) prior to Cache.evict(...), uses a file-based cache store, using passivation=true, purgeOnStartup=true, purgeSynchronously=true, fetchPersistentState=true
                
> DeltaAware based fine-grained replication corrupts cache data, if eviction is enabled
> -------------------------------------------------------------------------------------
>
>                 Key: ISPN-2974
>                 URL: https://issues.jboss.org/browse/ISPN-2974
>             Project: Infinispan
>          Issue Type: Bug
>    Affects Versions: 5.2.1.Final, 5.2.5.Final
>            Reporter: Horia Chiorean
>            Assignee: Adrian Nistor
>            Priority: Critical
>              Labels: 5.2.x
>             Fix For: 5.2.6.Final, 5.3.0.Beta1
>
>
> When using a custom {{DeltaAware}} implementation in a cluster with 2 replicated nodes with eviction enabled, data transferred from one node (the writer) to the another (the reader) causes data stored on this node and evicted at the time of the change, to be rewritten with whatever the partial latest delta was. 
> In more detail:
> * configure 2 nodes in replicated mode, with eviction enabled
> * consider NodeA the writer and NodeB the reader
> * NodeA inserts some data (custom entries) into the cache
> * NodeB correctly receives via state transfer the initial data
> * NodeA loads & partially updates some information about an entry which was not in the cache - was evicted previously
> * NodeB receives the partial delta with the changes from NodeA, but *instead of merging* with whatever is stored in the persistent store, *replaces the entire entry in the cache*, leaving it in effect with "partial/corrupt information"
> If eviction is not enabled, everything works as expected.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira