[
https://issues.apache.org/activemq/browse/SM-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=45137#action_45137
]
Ryan Moquin commented on SM-1519:
---------------------------------
I figured out the issue. I was playing around with different ways of using the
ServiceMixClient to avoid NPEs I seemed to get when reusing the DeliveryChannel
or ComponentContext. I ended trying an example that simplified communications
to the point that messages were created without specifying a MEP (I think is
the right acronym) type for the message and defaults to InOut. As a result, I
wasn't setting the exchange status to done and therefore I hung all the threads
in the container.
I'm not sure if it would be useful to address the fact that the container hangs
like this if the exchange isn't handled properly, or if there is a way to help
a developer to realize there mistake when they change their code and mistakenly
end up with the wrong type of MEP for the service invocation.
> JMS Consumer -> Servicemix-Bean -> JMS Provider deadlocks servicemix-bean
> service
> ---------------------------------------------------------------------------------
>
> Key: SM-1519
> URL: https://issues.apache.org/activemq/browse/SM-1519
> Project: ServiceMix
> Issue Type: Bug
> Components: servicemix-bean
> Affects Versions: 3.3
> Environment: Windows XP, Servicemix 3.3-SNAPSHOT
> Reporter: Ryan Moquin
> Priority: Blocker
> Attachments: bridge-test.zip
>
>
> We have a project that is using Servicemix to do processing. We have a JMS
> Consumer endpoint that takes an input message, forwards it to a
> Servicemix-Bean component, does some processing, then sends a generated
> message to a JMS Provider endpoint.
> This used to happen only some of the time, but recently, this started to
> become a problem to the point that our service locks every since time it hits
> about 1300 messages processed. I created a sample SA project, with a simple
> JMS client that will reproduce the problem.
> In order to reproduce, I did the following steps:
> 1. Build the attached project with Maven 2.
> 2. Downloaded and unzip the latest servicemix 3.3-SNAPSHOT distribution
> (though this problem also manifests itself on Servicemix 3.2.2 and I think
> also 3.2.1).
> 3. Copy the built bridge-test-sa-3.3-SNAPSHOT.jar artifact into the
> servicemix hotdeploy directory.
> 4. Start up servicemix.
> 5. After it has startup and everything is deployed, run the jms client which
> will send 2000 messages at 50 ms. intervals.
> 6. At about 1320 messages, the service typically freezes for a few seconds,
> then it unfreezes and 20 more messages will be processed. You can watch the
> amount of messages that go across in the jmx console.
> There is one more thing you can do that generates a different behavior but I
> think the same problem. The attached project by default is using the old jms
> endpoint for the consumer. This creates the deadlock after 1340 messages
> approx. In the bridge-jms-one-su project, the xbean.xml has a commented jms
> endpoint using the new servicemix-jms consumer endpoint and a pooled jms
> connection factory. If you uncomment that configuration and comment the
> other, when you perform the above steps, the servicemix-bean service will
> freeze after only 1 message has made it to the JMS provider.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
