[
https://issues.jboss.org/browse/ISPN-2974?page=com.atlassian.jira.plugin....
]
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