[jboss-jira] [JBoss JIRA] Commented: (JBCACHE-1298) Removal of non-existent node leaves invalid tombstone on remote nodes

[Brian Stansberry (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBCACHE-1298?page=comments#action_12400765 ] 
            
Brian Stansberry commented on JBCACHE-1298:
-------------------------------------------

This problem extends beyond the "removal" issue -- even ordinary invalidations fail when an explicit DataVersion is set on the node that originates the invalidation.

On the node that receives the invalidate() call, if the node in question doesn't exist, a tombstone with a DefaultDataVersion is created. Then _removeData(null, fqn, false, false, true, versionToInvalidate) is invoked, where "versionToInvalidate" is the version provided by the origin cache.

This fails with a custom DataVersion type (and would presumably fail with a DefaultDataVersion.ZERO):

13:24:08,768  WARN RemoteCacheInvocationDelegate:120 - replication failure with methodCall MethodName: invalidate; MethodIdInteger: 47; Args: (/test/com/foo/test/ENTITY/KEY0, org.hibernate.cache.jbc2.util.DataVersionAdapter at 121b59a [current=2, previous=1, src=org.hibernate.cache.impl.CacheDataDescriptionImpl at 19ecd80]) exception
org.jboss.cache.CacheException: Unable to validate versions.
	at org.jboss.cache.CacheImpl.findNode(CacheImpl.java:2250)
	at org.jboss.cache.CacheImpl.findNode(CacheImpl.java:2230)
	at org.jboss.cache.CacheImpl._removeData(CacheImpl.java:1443)
	at org.jboss.cache.CacheImpl.invalidate(CacheImpl.java:1626)

> Removal of non-existent node leaves invalid tombstone on remote nodes
> ---------------------------------------------------------------------
>
>                 Key: JBCACHE-1298
>                 URL: http://jira.jboss.com/jira/browse/JBCACHE-1298
>             Project: JBoss Cache
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Replication, Optimistic Locking
>            Reporter: Brian Stansberry
>         Assigned To: Manik Surtani
>             Fix For: 2.1.0.CR4
>
>
> Problem with optimistic locking and invalidation:
> Say node with Fqn "/a" doesn't exist in memory in any cache in cluster.
> On node1, call to cache.removeNode("/a") is made.  This is a valid call even though "/a" doesn't exist in the local cache -- caller wants it removed/invalidated across the cluster.
> This results in an invalidate() call around the cluster for "/a".  Since "/a" doesn't exist, no DataVersion is passed with the call.
> On other nodes in the cluster, the invalidate() method detects that "/a" doesn't exist locally.  So, invalidate() creates a tombstone for "/a".  Tombstone gets initialized with a DefaultDataVersion.  Since no other DataVersion was passed with the call, the tombstone gets left with that DefaultDataVersion.
> Now on node2 an attempt is made to do a put to "/a", passing in a DataVersion.  The put fails with a version conflict due to the presence of the tombstone.
> InvalidationInterceptorTest.testAddOfDeletedNonExistent() shows the problem.  This same issue is coming up in the Hibernate/JBC integration tests.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira