]
Galder Zamarreno commented on JBCACHE-1544:
-------------------------------------------
Having looked at this potential fix further, invalidation and replication after eviction
will likely have issues with OL because all the OL validation part relies on several
assumptions on when nodes are created and deleted. If we remove the node deletion part
from the evict() call, the OL validation parts fail when dealing with invalidations and
this is quite sensitive part of the OL code. Hence, for the moment, I'm abandoning
this fix and focusing on whether something around JBCACHE-1545 could be done.
Optimistic locking and eviction
-------------------------------
Key: JBCACHE-1544
URL:
https://jira.jboss.org/jira/browse/JBCACHE-1544
Project: JBoss Cache
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 1.4.1.SP13
Reporter: Mircea Markus
Assignee: Galder Zamarreno
Attachments: cluster-evictor.tar.gz, jboss-cache-jdk50.jar,
optimistic-replicated-eviction.xml, OptimisticReplicatedEvictionTest.java, patch-v1.txt
Since eviction is done per node, it is easy to get the cache into a bad
state. For example, a 2-node cluster, OPTIMISTIC, REPL_SYNC, 60 second
eviction:
On Node A:
cache.put ( "/foo", 0, 0 ); // this could be from any node
for ( ;; ) {
Thread.sleep ( 30000 ); // wait 30 seconds
cache.get ( "/foo", 0 ); // refresh the eviction timer so the node will
never be evicted on A
}
---------
This is just using the default JBC versioning, and direct cache access.
No hibernate.
There's no special configuration for the cache except what I listed
(OPTIMISTIC, REPL_SYNC, 60 second
eviction). No code hitting the cache except what I listed below.
By the way, this is EAP 4.3 CP05 (JBC 1.4.1.SP13).
On Node B:
// wait at least 60 seconds after the original put for the node to be
evicted on B
cache.put ( "/foo", 0, 0 ); // will always fail during replication to A:
org.jboss.cache.optimistic.DataVersioningException: DataNode [/foo]
version Ver=2 is newer than workspace node Ver=1
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: