You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Dominique Pfister (JIRA)" <ji...@apache.org> on 2011/02/07 11:11:30 UTC
[jira] Created: (JCR-2881) Deadlock on version operations in a
clustered environment
Deadlock on version operations in a clustered environment
---------------------------------------------------------
Key: JCR-2881
URL: https://issues.apache.org/jira/browse/JCR-2881
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: clustering
Affects Versions: 2.2.2
Reporter: Dominique Pfister
Assignee: Dominique Pfister
Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2881) Deadlock on version operations in a
clustered environment
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-2881:
-------------------------------
Fix Version/s: 2.1.4
Merged to the 2.1 branch in revision 1069811.
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.2
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Fix For: 2.1.4, 2.2.4
>
> Attachments: jackrabbit-core-2.2.3.patch
>
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2881) Deadlock on version operations in a
clustered environment
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dominique Pfister updated JCR-2881:
-----------------------------------
Status: Patch Available (was: Open)
Patch submitted.
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.3
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Attachments: jackrabbit-core-2.2.3.patch
>
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2881) Deadlock on version operations in a
clustered environment
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991327#comment-12991327 ]
Dominique Pfister commented on JCR-2881:
----------------------------------------
Fixed in revision 1067901 in trunk.
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.3
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Attachments: jackrabbit-core-2.2.3.patch
>
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2881) Deadlock on version operations in a
clustered environment
Posted by "John Langley (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991964#comment-12991964 ]
John Langley commented on JCR-2881:
-----------------------------------
I am seeing this same behavior in 2.1.3... What's the likelihood of porting this back to the 2.1 branch?
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.2
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Fix For: 2.2.4
>
> Attachments: jackrabbit-core-2.2.3.patch
>
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-2881) Deadlock on version operations in a
clustered environment
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991326#comment-12991326 ]
Dominique Pfister commented on JCR-2881:
----------------------------------------
Solution looks as follows: when doing a cluster sync, whether it is for reading or writing, always acquire a the version manager's read lock first.
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.3
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Attachments: jackrabbit-core-2.2.3.patch
>
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2881) Deadlock on version operations in a
clustered environment
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dominique Pfister updated JCR-2881:
-----------------------------------
Affects Version/s: (was: 2.2.2)
2.2.3
Status: Patch Available (was: Open)
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.3
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2881) Deadlock on version operations in a
clustered environment
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dominique Pfister updated JCR-2881:
-----------------------------------
Status: Open (was: Patch Available)
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.3
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2881) Deadlock on version operations in a
clustered environment
Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jukka Zitting updated JCR-2881:
-------------------------------
Affects Version/s: (was: 2.2.4)
2.2.2
Fix Version/s: 2.2.4
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.2
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Fix For: 2.2.4
>
> Attachments: jackrabbit-core-2.2.3.patch
>
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2881) Deadlock on version operations in a
clustered environment
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dominique Pfister updated JCR-2881:
-----------------------------------
Resolution: Fixed
Status: Resolved (was: Patch Available)
Fixed in 2.2 branch in revision 1067910.
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.3
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Attachments: jackrabbit-core-2.2.3.patch
>
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (JCR-2881) Deadlock on version
operations in a clustered environment
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991326#comment-12991326 ]
Dominique Pfister edited comment on JCR-2881 at 2/7/11 10:26 AM:
-----------------------------------------------------------------
Solution looks as follows: when doing a cluster sync, whether it is for reading or writing, always acquire the version manager's read lock first.
was (Author: dpfister):
Solution looks as follows: when doing a cluster sync, whether it is for reading or writing, always acquire a the version manager's read lock first.
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.3
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Attachments: jackrabbit-core-2.2.3.patch
>
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (JCR-2881) Deadlock on version operations in a
clustered environment
Posted by "Dominique Pfister (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dominique Pfister updated JCR-2881:
-----------------------------------
Attachment: jackrabbit-core-2.2.3.patch
Patch
> Deadlock on version operations in a clustered environment
> ---------------------------------------------------------
>
> Key: JCR-2881
> URL: https://issues.apache.org/jira/browse/JCR-2881
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: clustering
> Affects Versions: 2.2.3
> Reporter: Dominique Pfister
> Assignee: Dominique Pfister
> Attachments: jackrabbit-core-2.2.3.patch
>
>
> Version operations in a cluster may end up in a deadlock: a write operation in the version store will acquire the version manager's write lock (N1.VW) and subsequently the cluster journal's write lock (N1.JW). Another cluster node's write operation in some workspace will acquire the journal's write lock (N2.JW) and first process the journal record log: if some of these changes concern the version store, the version manager's read lock (N2.VR) has to be acquired in order to deliver them. If the first cluster node reaches N1.VW, and the second reaches N2.JW, we have a deadlock. The same scenario takes place when the second cluster node synchronizes to the latest journal changes and reaches N2.JR, when the first cluster node is in N1.VW.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira