[
https://issues.apache.org/jira/browse/JCR-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved JCR-790.
----------------------------------
Resolution: Duplicate
And a duplicate of JCR-672
> Possible deadlock during concurrent operations on versionable nodes
> -------------------------------------------------------------------
>
> Key: JCR-790
> URL: https://issues.apache.org/jira/browse/JCR-790
> Project: Jackrabbit
> Issue Type: Bug
> Components: versioning
> Affects Versions: 1.2.1
> Reporter: Olivier Dony
> Attachments: jackrabbit-thread-dump.log.zip,
> thread-dump-analysis.txt.zip
>
>
> As discussed on the dev mailing-list:
> We are using the Repository Server deployment model for one of our systems,
> with 3 different web applications using the same jackrabbit 1.2.1 server.
> Two of the webapps are read-only frontoffice clients, the third one is a
> read-write backoffice.
> Sometimes the jackrabbit-server enters a deadlock and stops answering
> requests until it is restarted. A thread dump of the deadlock situation is
> attached.
> From the thread dump analysis provided by Marcel Reutegger (attached too), it
> appears that two threads are indeed deadlocked while attempting to save()
> versionable items, after acquiring locks (Workspace SISM/VersionManager) in
> different orders.
> This appears to be the case only because the items being saved are
> versionable, and because one of them is a new item, which means that the
> VersionHistory is being created.
> We couldn't find an easy way to reproduce this concurrency issue, as it
> doesn't happen very often, but it takes down our whole system when it does.
> Note: if that matters, some of the client applications are using
> jackrabbit-jcr-rmi-1.1.jar and jackrabbit-jcr-core-1.1.jar to talk to this
> jackrabbit 1.2.1 server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
