You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by "Freeman Fang (JIRA)" <ji...@apache.org> on 2009/04/08 07:29:34 UTC

[jira] Commented: (SM-1840) AutoDeploymentService hangs on deployment of cxf-bc & smx-jmx in-out jms consumer when in-out provider has already placed messages on queue

    [ https://issues.apache.org/activemq/browse/SM-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51096#action_51096 ] 

Freeman Fang commented on SM-1840:
----------------------------------

Hi Ron,

Just figure out how the hang happen
You work flow is 
wsdl-first-cxf-bridge-sa.jar - cxf-bc http (in-out) consumer -> cxf-bc jms (in-out) provider -->
wsdl-first-cxf-sa.jar - cxf-bc jms (in-out) consumer -> cxf-se (in-out) PersonImpl
You deploy wsdl-first-cxf-bridge-sa.jar first and send request to cxf-bc http (in-out) consumer with client.html, since at this time wsdl-first-cxf-sa.jar not deploy yet, so mesage exchange send from cxf-bc http (in-out) consumer to cxf-bc jms (in-out) provider will wait for the response, which means the ReentrantReadWriteLock.ReadLock is holded by the flow.
And then you deploy wsdl-first-cxf-sa.jar, which in turn AbstractFlow.suspend() get invoked which will try to grap the ReentrantReadWriteLock.WriteLock(only success if no other thread hold the ReentrantReadWriteLock.ReadLock and WriteLock, otherwise will hang), but it's impossible since the ReentrantReadWriteLock.ReadLock can't be released until the cxf-bc http (in-out) consumer get response mesasge exchange (which means it wait for wsdl-first-cxf-sa.jar deploy sucessfully, but wsdl-first-cxf-sa.jar deploy need the writelock first ). You see the deadlock happen then.
We could use ReentrantReadWriteLock.WriteLock.tryLock specifying the timeout to break the deadlock.

Freeman


> AutoDeploymentService hangs on deployment of cxf-bc & smx-jmx in-out jms consumer when in-out provider has already placed messages on queue
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SM-1840
>                 URL: https://issues.apache.org/activemq/browse/SM-1840
>             Project: ServiceMix
>          Issue Type: Bug
>          Components: servicemix-core
>    Affects Versions: 3.2.4
>         Environment: JDK 5 Update 18, Windows XP, SMX 3.2.4-SNAPSHOT (4/6/2009)
>            Reporter: Ron Gavlin
>            Assignee: Freeman Fang
>            Priority: Critical
>         Attachments: client.html, cxf-wsdl-first-http2jms-src.zip, wsdl-first-cxf-bridge-sa.jar, wsdl-first-cxf-sa.jar
>
>
> Attached, please find two service assemblies, wsdl-first-cxf-bridge-sa.jar and wsdl-first-cxf-sa.jar. Perform the following steps to reproduce this critical issue:
> 1. Start SMX
> 2. Deploy wsdl-first-cxf-bridge-sa.jar
> 3. Open the cxf-wsdl-first client.html in a browser and send a request message (note that a jms message is placed on the ActiveMQ person.queue queue)
> 4. Deploy wsdl-first-cxf-sa.jar (note that the AutoDeploymentService hangs while attempting to deploy this service assembly)
> The following thread dump, generated by a ctrl-break, provides insight into the state of the hung AutoDeploymentService thread:
> {quote}
> "Timer-4" daemon prio=6 tid=0x2880bbc8 nid=0x1074 waiting on condition [0x2accf000..0x2accfb18]
>         at sun.misc.Unsafe.park(Native Method)
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:118)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:7
> 16)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:746)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1076)
>         at org.apache.servicemix.locks.ReentrantReadWriteLock$NonfairSync.wlock(ReentrantReadWriteLock.java:245)
>         at org.apache.servicemix.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:545)
>         at org.apache.servicemix.jbi.nmr.flow.AbstractFlow.suspend(AbstractFlow.java:136)
>         - locked <0x077f1fa0> (a org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow)
>         at org.apache.servicemix.jbi.nmr.DefaultBroker.suspend(DefaultBroker.java:250)
>         at org.apache.servicemix.jbi.framework.AutoDeploymentService.updateArchive(AutoDeploymentService.java:250)
>         at org.apache.servicemix.jbi.framework.AutoDeploymentService.monitorDirectory(AutoDeploymentService.java:667)
>         at org.apache.servicemix.jbi.framework.AutoDeploymentService.access$800(AutoDeploymentService.java:62)
>         at org.apache.servicemix.jbi.framework.AutoDeploymentService$1.run(AutoDeploymentService.java:631)
>         at java.util.TimerThread.mainLoop(Timer.java:512)
>         at java.util.TimerThread.run(Timer.java:462)
> {quote}
> Please let me know if you would like the sources for this project. Also, please note that this problem also occurs when the smx-cxf-bc in-out jms provider and consumer endpoints are replaced with either the new or old smx-jmx endpoints.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.