]
Galder Zamarreno updated JBCACHE-1544:
--------------------------------------
Attachment: optimistic-replicated-eviction.xml
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: optimistic-replicated-eviction.xml,
OptimisticReplicatedEvictionTest.java
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: