[
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.
