You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Olivier Dony (JIRA)" <ji...@apache.org> on 2007/03/14 12:32:11 UTC
[jira] Created: (JCR-790) Possible deadlock during concurrent
operations on versionable nodes
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
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.
[jira] Updated: (JCR-790) Possible deadlock during concurrent
operations on versionable nodes
Posted by "Olivier Dony (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Olivier Dony updated JCR-790:
-----------------------------
Attachment: jackrabbit-thread-dump.log.zip
This is the (huge) thread dump of the deadlock situation.
> 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
>
>
> 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.
[jira] Resolved: (JCR-790) Possible deadlock during concurrent
operations on versionable nodes
Posted by "Marcel Reutegger (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (JCR-790) Possible deadlock during concurrent
operations on versionable nodes
Posted by "Olivier Dony (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Olivier Dony updated JCR-790:
-----------------------------
Attachment: thread-dump-analysis.txt.zip
This is the analysis of the locking performed by the 2 deadlocked threads, provided by Marcel Reutegger.
> 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.