| Key: |
JCR-790
|
| Type: |
Bug
|
| Status: |
Closed
|
| Resolution: |
Duplicate
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Olivier Dony
|
| Votes: |
0
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
File Attachments:
|
|
|
Issue Links:
|
Duplicate
|
|
This issue duplicates:
|
|
JCR-672
Deadlock on concurrent save/checkin operations possible
|
|
|
|
|
|
Reference
|
|
This issue relates to:
|
|
|
JCR-18
Multithreading issue with versioning
|
|
|
|
|
|
|
|
| Resolution Date: |
27/Apr/07 03:50 PM
|
|
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.
|
|
Description
|
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. |
Show » |
|
