You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ace.apache.org by "Dennis Geurts (JIRA)" <ji...@apache.org> on 2011/01/13 22:34:45 UTC
[jira] Created: (ACE-105) Deadlock on (client)
RepositoryAdmin.commit()
Deadlock on (client) RepositoryAdmin.commit()
---------------------------------------------
Key: ACE-105
URL: https://issues.apache.org/jira/browse/ACE-105
Project: Ace
Issue Type: Bug
Affects Versions: 0.8.0
Reporter: Dennis Geurts
Attachments: ace-roi.patch, dump.txt
During a commit of changes to the repository, I have reached a deadlock.
Basically, what happens is the following:
The commit() action triggers a call to commit on all repository sets. This triggers a serialization to XML of the repositories. During this action, each repository is set to busy, which eventually sets all contained RepositoryObject to busy ( i.e. RepositoryObjectImpl.setBusy() is called). This is where a lock is created, first on its attributes, then on its associations.
Meanwhile, based on a synchronous EventAdmin event, it is decided that a new deployment version is required for a particular target. During this deployment creation process, it is possible that we loop over all objects in the repository. During this process we end up in the getAssociations() call of the same RepositoryObjectImpl, that was just set to busy. Unfortunately, this call to getAssociations() first locks the contained associations. Then, during the equals() call, a lock is created on the contained attributes.
This can lead to a deadlock. I will attach a threaddump that reproduces the issue.
I propose the following patch (see attachemnt) where in the RepositoryObjectImpl.setBusy() call the lock order is reversed.
After applying this patch locally, I have not been able to reproduce this deadlock anymore.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ACE-105) Deadlock on (client)
RepositoryAdmin.commit()
Posted by "Dennis Geurts (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Geurts updated ACE-105:
------------------------------
Description:
During a commit of changes to the repository, I have reached a deadlock.
Basically, what happens is the following:
The commit() action triggers a call to commit on all repository sets. This triggers a serialization to XML of the repositories. During this action, each repository is set to busy, which eventually sets all contained RepositoryObject to busy ( i.e. RepositoryObjectImpl.setBusy() is called). This is where a lock is created, first on its attributes, then on its associations.
Meanwhile, based on an asynchronous EventAdmin event, it is decided that a new deployment version is required for a particular target. During this deployment creation process, it is possible that we loop over all objects in the repository. During this process we end up in the getAssociations() call of the same RepositoryObjectImpl, that was just set to busy. Unfortunately, this call to getAssociations() first locks the contained associations. Then, during the equals() call, a lock is created on the contained attributes.
This can lead to a deadlock. I will attach a threaddump that reproduces the issue.
I propose the following patch (see attachemnt) where in the RepositoryObjectImpl.setBusy() call the lock order is reversed.
After applying this patch locally, I have not been able to reproduce this deadlock anymore.
was:
During a commit of changes to the repository, I have reached a deadlock.
Basically, what happens is the following:
The commit() action triggers a call to commit on all repository sets. This triggers a serialization to XML of the repositories. During this action, each repository is set to busy, which eventually sets all contained RepositoryObject to busy ( i.e. RepositoryObjectImpl.setBusy() is called). This is where a lock is created, first on its attributes, then on its associations.
Meanwhile, based on a synchronous EventAdmin event, it is decided that a new deployment version is required for a particular target. During this deployment creation process, it is possible that we loop over all objects in the repository. During this process we end up in the getAssociations() call of the same RepositoryObjectImpl, that was just set to busy. Unfortunately, this call to getAssociations() first locks the contained associations. Then, during the equals() call, a lock is created on the contained attributes.
This can lead to a deadlock. I will attach a threaddump that reproduces the issue.
I propose the following patch (see attachemnt) where in the RepositoryObjectImpl.setBusy() call the lock order is reversed.
After applying this patch locally, I have not been able to reproduce this deadlock anymore.
> Deadlock on (client) RepositoryAdmin.commit()
> ---------------------------------------------
>
> Key: ACE-105
> URL: https://issues.apache.org/jira/browse/ACE-105
> Project: Ace
> Issue Type: Bug
> Affects Versions: 0.8.0
> Reporter: Dennis Geurts
> Attachments: ace-roi.patch, dump.txt
>
>
> During a commit of changes to the repository, I have reached a deadlock.
> Basically, what happens is the following:
> The commit() action triggers a call to commit on all repository sets. This triggers a serialization to XML of the repositories. During this action, each repository is set to busy, which eventually sets all contained RepositoryObject to busy ( i.e. RepositoryObjectImpl.setBusy() is called). This is where a lock is created, first on its attributes, then on its associations.
> Meanwhile, based on an asynchronous EventAdmin event, it is decided that a new deployment version is required for a particular target. During this deployment creation process, it is possible that we loop over all objects in the repository. During this process we end up in the getAssociations() call of the same RepositoryObjectImpl, that was just set to busy. Unfortunately, this call to getAssociations() first locks the contained associations. Then, during the equals() call, a lock is created on the contained attributes.
> This can lead to a deadlock. I will attach a threaddump that reproduces the issue.
> I propose the following patch (see attachemnt) where in the RepositoryObjectImpl.setBusy() call the lock order is reversed.
> After applying this patch locally, I have not been able to reproduce this deadlock anymore.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (ACE-105) Deadlock on (client)
RepositoryAdmin.commit()
Posted by "Dennis Geurts (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Geurts closed ACE-105.
-----------------------------
yes, I'm delighted. Thank you so much for the prompt response!
> Deadlock on (client) RepositoryAdmin.commit()
> ---------------------------------------------
>
> Key: ACE-105
> URL: https://issues.apache.org/jira/browse/ACE-105
> Project: Ace
> Issue Type: Bug
> Affects Versions: 0.8.0
> Reporter: Dennis Geurts
> Assignee: Angelo van der Sijpt
> Attachments: ace-roi.patch, dump.txt
>
>
> During a commit of changes to the repository, I have reached a deadlock.
> Basically, what happens is the following:
> The commit() action triggers a call to commit on all repository sets. This triggers a serialization to XML of the repositories. During this action, each repository is set to busy, which eventually sets all contained RepositoryObject to busy ( i.e. RepositoryObjectImpl.setBusy() is called). This is where a lock is created, first on its attributes, then on its associations.
> Meanwhile, based on an asynchronous EventAdmin event, it is decided that a new deployment version is required for a particular target. During this deployment creation process, it is possible that we loop over all objects in the repository. During this process we end up in the getAssociations() call of the same RepositoryObjectImpl, that was just set to busy. Unfortunately, this call to getAssociations() first locks the contained associations. Then, during the equals() call, a lock is created on the contained attributes.
> This can lead to a deadlock. I will attach a threaddump that reproduces the issue.
> I propose the following patch (see attachemnt) where in the RepositoryObjectImpl.setBusy() call the lock order is reversed.
> After applying this patch locally, I have not been able to reproduce this deadlock anymore.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ACE-105) Deadlock on (client)
RepositoryAdmin.commit()
Posted by "Angelo van der Sijpt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Angelo van der Sijpt resolved ACE-105.
--------------------------------------
Resolution: Fixed
I've checked and applied your patch; please close if delighted.
> Deadlock on (client) RepositoryAdmin.commit()
> ---------------------------------------------
>
> Key: ACE-105
> URL: https://issues.apache.org/jira/browse/ACE-105
> Project: Ace
> Issue Type: Bug
> Affects Versions: 0.8.0
> Reporter: Dennis Geurts
> Assignee: Angelo van der Sijpt
> Attachments: ace-roi.patch, dump.txt
>
>
> During a commit of changes to the repository, I have reached a deadlock.
> Basically, what happens is the following:
> The commit() action triggers a call to commit on all repository sets. This triggers a serialization to XML of the repositories. During this action, each repository is set to busy, which eventually sets all contained RepositoryObject to busy ( i.e. RepositoryObjectImpl.setBusy() is called). This is where a lock is created, first on its attributes, then on its associations.
> Meanwhile, based on an asynchronous EventAdmin event, it is decided that a new deployment version is required for a particular target. During this deployment creation process, it is possible that we loop over all objects in the repository. During this process we end up in the getAssociations() call of the same RepositoryObjectImpl, that was just set to busy. Unfortunately, this call to getAssociations() first locks the contained associations. Then, during the equals() call, a lock is created on the contained attributes.
> This can lead to a deadlock. I will attach a threaddump that reproduces the issue.
> I propose the following patch (see attachemnt) where in the RepositoryObjectImpl.setBusy() call the lock order is reversed.
> After applying this patch locally, I have not been able to reproduce this deadlock anymore.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ACE-105) Deadlock on (client)
RepositoryAdmin.commit()
Posted by "Angelo van der Sijpt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Angelo van der Sijpt reassigned ACE-105:
----------------------------------------
Assignee: Angelo van der Sijpt
> Deadlock on (client) RepositoryAdmin.commit()
> ---------------------------------------------
>
> Key: ACE-105
> URL: https://issues.apache.org/jira/browse/ACE-105
> Project: Ace
> Issue Type: Bug
> Affects Versions: 0.8.0
> Reporter: Dennis Geurts
> Assignee: Angelo van der Sijpt
> Attachments: ace-roi.patch, dump.txt
>
>
> During a commit of changes to the repository, I have reached a deadlock.
> Basically, what happens is the following:
> The commit() action triggers a call to commit on all repository sets. This triggers a serialization to XML of the repositories. During this action, each repository is set to busy, which eventually sets all contained RepositoryObject to busy ( i.e. RepositoryObjectImpl.setBusy() is called). This is where a lock is created, first on its attributes, then on its associations.
> Meanwhile, based on an asynchronous EventAdmin event, it is decided that a new deployment version is required for a particular target. During this deployment creation process, it is possible that we loop over all objects in the repository. During this process we end up in the getAssociations() call of the same RepositoryObjectImpl, that was just set to busy. Unfortunately, this call to getAssociations() first locks the contained associations. Then, during the equals() call, a lock is created on the contained attributes.
> This can lead to a deadlock. I will attach a threaddump that reproduces the issue.
> I propose the following patch (see attachemnt) where in the RepositoryObjectImpl.setBusy() call the lock order is reversed.
> After applying this patch locally, I have not been able to reproduce this deadlock anymore.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ACE-105) Deadlock on (client)
RepositoryAdmin.commit()
Posted by "Dennis Geurts (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ACE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dennis Geurts updated ACE-105:
------------------------------
Attachment: ace-roi.patch
dump.txt
the thread dump and proposed patch
> Deadlock on (client) RepositoryAdmin.commit()
> ---------------------------------------------
>
> Key: ACE-105
> URL: https://issues.apache.org/jira/browse/ACE-105
> Project: Ace
> Issue Type: Bug
> Affects Versions: 0.8.0
> Reporter: Dennis Geurts
> Attachments: ace-roi.patch, dump.txt
>
>
> During a commit of changes to the repository, I have reached a deadlock.
> Basically, what happens is the following:
> The commit() action triggers a call to commit on all repository sets. This triggers a serialization to XML of the repositories. During this action, each repository is set to busy, which eventually sets all contained RepositoryObject to busy ( i.e. RepositoryObjectImpl.setBusy() is called). This is where a lock is created, first on its attributes, then on its associations.
> Meanwhile, based on a synchronous EventAdmin event, it is decided that a new deployment version is required for a particular target. During this deployment creation process, it is possible that we loop over all objects in the repository. During this process we end up in the getAssociations() call of the same RepositoryObjectImpl, that was just set to busy. Unfortunately, this call to getAssociations() first locks the contained associations. Then, during the equals() call, a lock is created on the contained attributes.
> This can lead to a deadlock. I will attach a threaddump that reproduces the issue.
> I propose the following patch (see attachemnt) where in the RepositoryObjectImpl.setBusy() call the lock order is reversed.
> After applying this patch locally, I have not been able to reproduce this deadlock anymore.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.