[jira] Updated: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.

["Ryan Brush (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/JCR-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Brush updated JCR-1440:
----------------------------

    Attachment: jcr-1440-workaround.patch

I ran into this issue in a similar situation.  Debugging in jackrabbit-core-1.4.2, I found that the InternalVersionHistoryImpl contains caches that were not aware of this update made by another node in the cluster.  It's not clear to me how these caches are (or should be) synchronized, but I was able to work around the problem by adding the following logic to InternalVersionHistoryImpl#getVersion(NodeId):

* Run the existing logic to find the version in cache. 
* If the cached version is found, return it.
* If it is not found, invoke InternalVersionHistoryImpl#reload() to ensure newer changes to the repository are visible to the cache
* Attempt to get the item from cache again now that we've loaded the latest state

I don't know if this is an appropriate fix, or if there is some other workaround we might use.  However, this might shed some light on what is happening here.  I imagine the reload() operation can be expensive, but it shouldn't be called during a normal flow.

I'm also trying to better understand the threading model in Jackrabbit to ensure this mutation doesn't cause any race condition.


> NPE Thrown when two Cluster Nodes are hitting the same underlying database.
> ---------------------------------------------------------------------------
>
>                 Key: JCR-1440
>                 URL: https://issues.apache.org/jira/browse/JCR-1440
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: clustering, jackrabbit-core
>    Affects Versions: 1.4, core 1.4.1
>         Environment: Vista JDK 1.5.0_12.  Using Derby and Derby Client 10.1.2.1
>            Reporter: Micah Whitacre
>            Priority: Critical
>         Attachments: jcr-1440-workaround.patch, repository1.xml, SimpleJackrabbitConflictTest.java, SimpleJackRabbitTest.zip
>
>
> I've created a test that creates two repositories with clustering enabled that are backed by the same database.  Using the following workflow causes a NullPointerException to be thrown.
> The workflow I'm using is:
> The root node is versioned.
> ClusterNode1 creates a versioned child node named "foo".
> The test waits to make sure the syncDelay has passed so ClusterNode2 will notice the newly created node.
> ClusterNode2 retrieves the "foo" child node and removes it.
> The test waits for the change ClusterNode1 to sync with that change.
> ClusterNode1 tries to create another new node however a NullPointerException is thrown when the it tries to checkout the rootNode.
> java.lang.NullPointerException: null values not allowed
> 	at org.apache.commons.collections.map.AbstractReferenceMap.put(AbstractReferenceMap.java:251)
> 	at org.apache.jackrabbit.core.version.VersionManagerImpl.getItem(VersionManagerImpl.java:280)
> 	at org.apache.jackrabbit.core.version.XAVersionManager.getItem(XAVersionManager.java:334)
> 	at org.apache.jackrabbit.core.version.AbstractVersionManager.getVersion(AbstractVersionManager.java:87)
> 	at org.apache.jackrabbit.core.NodeImpl.getBaseVersion(NodeImpl.java:3198)
> 	at org.apache.jackrabbit.core.NodeImpl.checkout(NodeImpl.java:2991)
> 	at com.cerner.system.configuration.repository.jcr.SimpleJackrabbitConflictTest.testNullPointerExceptionThrown(SimpleJackrabbitConflictTest.java:96)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.