10:06 a.m.
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)
Reporter: Mircea Markus
Assignee: Manik Surtani
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:42 p.m.
New subject: [JBoss JIRA] Assigned: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Galder Zamarreno reassigned JBCACHE-1544:
-----------------------------------------
Assignee: Galder Zamarreno (was: Manik Surtani)
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
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:42 p.m.
New subject: [JBoss JIRA] Work started: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Work on JBCACHE-1544 started by Galder Zamarreno.
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
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:42 p.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Galder Zamarreno updated JBCACHE-1544:
--------------------------------------
Affects Version/s: 1.4.1.SP13
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
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:26 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Dennis Reed commented on JBCACHE-1544:
--------------------------------------
One correction to the test case: The first cache.put() should be done multiple times, so
the version is >= 2.
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
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:30 p.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Dennis Reed updated JBCACHE-1544:
---------------------------------
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
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:06 p.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:06 p.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Galder Zamarreno updated JBCACHE-1544:
--------------------------------------
Attachment: OptimisticReplicatedEvictionTest.java
I'm attaching a unit test I've created to jira. I'll be uploading the config
file too.
I haven't looked at this in depth but an idea that comes to my mind is potentially
keeping version information around in spite of eviction. This would be slightly similar to
what happens with queries and timestamps in the 2nd level cache world. You need the
timestamps not to be evicted otherwise queries would resolve in the cache even though
entities have been evicted, leading to wrong query results.
Another (rather crazy) idea would be evictions to result on cluster wide removals cos that
would clear the version information everywhere. This might be a reasonably easy
workaround, could be implemented relatively easily with a Cache listener. I believe Jimmy
W had someone asking him for evictions to result in cluster wide removals. It'd be
interesting to find out whether something came out of that cos it'd potentially be
useful here.
I'll have a further think overnight and see if I can come up with more ideas.
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:56 a.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Galder Zamarreno updated JBCACHE-1544:
--------------------------------------
Attachment: patch-v1.txt
jboss-cache-jdk50.jar
I've got a potential one liner fix for this:
Index: src/org/jboss/cache/TreeCache.java
===================================================================
--- src/org/jboss/cache/TreeCache.java (revision 8231)
+++ src/org/jboss/cache/TreeCache.java (working copy)
@@ -5105,7 +5105,7 @@
boolean eviction = true;
if (log.isTraceEnabled())
log.trace("_evict(" + fqn + ")");
- if (hasChild(fqn))
+ if (hasChild(fqn) || isNodeLockingOptimistic())
{
_removeData(null, fqn, create_undo_ops, sendNodeEvent, eviction);
return false;
Basically, if optimistic, never evict the whole node, but just delete the data. This will
leave the version hanging around which makes the test in the patch pass.
I'm uploading a jboss-cache-jdk50.jar containing this patch.
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:17 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:36 p.m.
New subject: [JBoss JIRA] Resolved: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Galder Zamarreno resolved JBCACHE-1544.
---------------------------------------
Resolution: Won't Fix
Issues like this are a result of storing data version in the node itself and as such, OL
is considered broken. In fact, it has been deprecated in JBoss Cache 3.x and removed in
Infinispan, hence it's use it's not recommended. As a workaround, you can use a
cluster wide eviction instead. Hence, this JIRA won't be fixed.
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:51 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Aleksander Adamowski commented on JBCACHE-1544:
-----------------------------------------------
Galder, does the workaround imply usage of the attached jboss-cache-jdk50.jar ?
What's the difference between this jar and the one attached in JBCACHE-1545?
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:52 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Galder Zamarreno commented on JBCACHE-1544:
-------------------------------------------
Aleksander, there's no workaround as such. The jar attached contains a potential fix
but we never ended up implementing it. The reasons can for not implementing it can be
found in my previous 2 comments. Difference between the jars? Well, they fix diff issues
:). I'll recommend not using OL, you'll be much better off.
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:52 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Aleksander Adamowski commented on JBCACHE-1544:
-----------------------------------------------
OK, and for something completely different, suppose we're willing to make an upgrade,
does Infinispan offer at least the level of concurrency found in TreeCache 1.4 configured
with optimistic locking?
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:01 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/jira/browse/JBCACHE-1544?page=com.atlassian.jira.p...
]
Aleksander Adamowski commented on JBCACHE-1544:
-----------------------------------------------
BTW, is it possible to include the recommendation against Optimistic Locking in the
current documentation?
Because currently it provides very favourable description of this mechanism, leading
people into a trap of actually using it:
http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs...
http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.2/doc/cache/Cache_Fr...
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:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:05 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-1544) Optimistic locking and eviction
[
https://jira.jboss.org/browse/JBCACHE-1544?page=com.atlassian.jira.plugin...
]
Galder Zamarreno commented on JBCACHE-1544:
-------------------------------------------
Aleksander, Infinispan provides better concurrency than PL or OL. It allows non-blocking
reads without having to copy the workspace. Write consistency is used with a similar
method to OL which allows readers to carry on.
Wrt documentation, you're right. I'll add a JIRA to get it done.
Optimistic locking and eviction
-------------------------------
Key: JBCACHE-1544
URL: https://jira.jboss.org/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:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5093
days inactive
5338
days old
jbosscache-issues@lists.jboss.org
15 comments
4 participants
participants (4)
-
Aleksander Adamowski (JIRA) -
Dennis Reed (JIRA)
-
Galder Zamarreno (JIRA)
-
Mircea Markus (JIRA)