jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Brush (JIRA)" <j...@apache.org>
Subject [jira] Updated: (JCR-1440) NPE Thrown when two Cluster Nodes are hitting the same underlying database.
Date Thu, 03 Apr 2008 16:42:24 GMT

     [ 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
>            Reporter: Micah Whitacre
>            Priority: Critical
>         Attachments: jcr-1440-workaround.patch, repository1.xml, SimpleJackrabbitConflictTest.java,
> 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.

View raw message