cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amichai Rothman (JIRA)" <>
Subject [jira] [Updated] (DOSGI-163) Deadlock when shutting down
Date Wed, 03 Apr 2013 15:23:16 GMT


Amichai Rothman updated DOSGI-163:

    Attachment: fix_importregistrationimpl_2.diff

Ok, here is an updated patch which should address both deadlocks. For the reviewer's convenience,
it is split into two patch files - the first is a bunch of cleanup, refactoring and documenting
which should make the class more clear, concise and straightforward (and hopefully less error-prone),
and the second is the actual synchronization fix on top of the first.

The first patch doesn't include any functional changes (except for log texts), but only makes
future changes easier and clearer (hopefully). It consists of the following changes:

- deleted ImportReferenceImpl, which was a simple wrapper delegating everything back to ImportRegistrationImpl,
and made the latter implement ImportReference directly instead (which it basically already
- added clarifying comments and javadocs
- renamed init() to initParent(), childs to children, and detatched to detached for clarity
and correctness
- reordered methods to be better grouped by their relationships
- unified checks for isFailure and closed into a single isInvalid() check
- removed redundant check of closed before calling close() (which already checks that)
- replaced cumbersome methods with simple returned conditionals
- removed unused methods
- removed accessors which were used only in one place (internally)
- made children use parent's importedService reference, instead of always setting the same
reference on all children

The second patch is the one that addresses the deadlock issue at hand, by reworking the synchronized
methods into finer synchronized blocks, such that they guard only the internal state of the
class from inconsistencies, but make sure that no locks are held when invoking external methods
(most of which have their own locks - the previous double-locking is how the deadlocks came
to be in the first place).

Comments, suggestions and corrections are most welcome (and committing the patches to trunk
too, if all is well! ;-) )

> Deadlock when shutting down
> ---------------------------
>                 Key: DOSGI-163
>                 URL:
>             Project: CXF Distributed OSGi
>          Issue Type: Bug
>          Components: DSW
>    Affects Versions: 1.4.0
>         Environment: Oracle JDK 1.7.0_17, Karaf 2.3.1, DOSGi 1.4.0
>            Reporter: Amichai Rothman
>         Attachments: fix_dosgi_unregister_deadlock.diff, fix_importregistrationimpl_1.diff,
> Karaf sometimes hangs while shutting down, and a thread dump shows a deadlock in DOSGi.
In general, the OSGi specs recommend not to hold any locks when calling the APIs since it
can result in a deadlock, as is the case here.
> A proposed fix calls ServiceRegistration.unregister outside of the synchronized block
in ImportRegistrationImpl.close (note that it still is synchronized when called from closeAll,
which may pose a related but separate problem - but the fix does fix this specific deadlock
as it was encountered here).
> Found one Java-level deadlock:
> =============================
> "pool-18-thread-3":
>   waiting to lock monitor 0x00007f0658003f40 (object 0x00000000e5b485b0, a org.eclipse.osgi.internal.serviceregistry.ServiceUse),
>   which is held by "Blueprint Extender: 2"
> "Blueprint Extender: 2":
>   waiting to lock monitor 0x00007f0654002a50 (object 0x00000000f1b70240, a org.apache.cxf.dosgi.dsw.service.ImportRegistrationImpl),
>   which is held by "pool-18-thread-3"
> Java stack information for the threads listed above:
> ===================================================
> "pool-18-thread-3":
>         at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.releaseService(
>         - waiting to lock <0x00000000e5b485b0> (a org.eclipse.osgi.internal.serviceregistry.ServiceUse)
>         at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(
>         at org.apache.cxf.dosgi.dsw.service.ImportRegistrationImpl.instanceClosed(
>         - locked <0x00000000f1b70240> (a org.apache.cxf.dosgi.dsw.service.ImportRegistrationImpl)
>         at org.apache.cxf.dosgi.dsw.service.ImportRegistrationImpl.close(
>         - locked <0x00000000f1b70240> (a org.apache.cxf.dosgi.dsw.service.ImportRegistrationImpl)
>         at org.apache.cxf.dosgi.topologymanager.importer.TopologyManagerImport.unexportNotAvailableServices(
>         at org.apache.cxf.dosgi.topologymanager.importer.TopologyManagerImport.access$200(
>         at org.apache.cxf.dosgi.topologymanager.importer.TopologyManagerImport$
>         - locked <0x00000000ea71b6c0> (a java.util.HashMap)
>         - locked <0x00000000ea71b6f8> (a java.util.HashMap)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
>         at java.util.concurrent.ThreadPoolExecutor$
>         at
> "Blueprint Extender: 2":
>         at org.apache.cxf.dosgi.dsw.service.ImportRegistrationImpl.closeAll(
>         - waiting to lock <0x00000000f1b70240> (a org.apache.cxf.dosgi.dsw.service.ImportRegistrationImpl)
>         at org.apache.cxf.dosgi.dsw.service.ClientServiceFactory.remove(
>         at org.apache.cxf.dosgi.dsw.service.ClientServiceFactory.ungetService(
>         - locked <0x00000000f1b6f7e0> (a org.apache.cxf.dosgi.dsw.service.ClientServiceFactory)
>         at org.eclipse.osgi.internal.serviceregistry.ServiceUse$
>         at Method)
>         at org.eclipse.osgi.internal.serviceregistry.ServiceUse.ungetService(
>         at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.ungetService(
>         - locked <0x00000000e5b485b0> (a org.eclipse.osgi.internal.serviceregistry.ServiceUse)
>         at org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.ungetService(
>         at org.eclipse.osgi.framework.internal.core.BundleContextImpl.ungetService(
>         at org.apache.aries.blueprint.container.ReferenceListRecipe$ServiceDispatcher.destroy(
>         - locked <0x00000000e5bab728> (a org.apache.aries.blueprint.container.ReferenceListRecipe$ServiceDispatcher)
>         at org.apache.aries.blueprint.container.ReferenceListRecipe.untrack(
>         - locked <0x00000000eaef82d0> (a java.lang.Object)
>         at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.serviceRemoved(
>         at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe.access$200(
>         at org.apache.aries.blueprint.container.AbstractServiceReferenceRecipe$
>         at java.util.concurrent.Executors$
>         at java.util.concurrent.FutureTask$Sync.innerRun(
>         at
>         at
>         at
>         at java.util.concurrent.Executors$
>         at java.util.concurrent.FutureTask$Sync.innerRun(
>         at
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(
>         at java.util.concurrent.ScheduledThreadPoolExecutor$
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
>         at java.util.concurrent.ThreadPoolExecutor$
>         at
> Found 1 deadlock.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message