[
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.
