[
https://issues.apache.org/activemq/browse/SMXCOMP-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan Moquin reopened SMXCOMP-713:
---------------------------------
Hi Jean,
I looked at what you commited to the source repository. Could you verify that
you also made the changes in the revised patch that I posted? It didn't look
like you did and if you don't, then a problem will occur with the
servicemix-http component if the exchange is sent via JMS flow. If that change
is in there then great. I've been using that second patch for quite a while
now and everything has been rock solid with no issues since.
BTW - that second patch only includes one extra line to attach the exchange
received to the continuation (this way if the exchange did change as a result
of going over jmsflow, when you replay the request, the correct exchange will
be used).
If you did use that second patch, I apologize. When I looked at the code it
didn't look like it was included.
Thanks!!
Ryan
> Threading problem in Servicemix-HTTP which renders the component unusable.
> --------------------------------------------------------------------------
>
> Key: SMXCOMP-713
> URL: https://issues.apache.org/activemq/browse/SMXCOMP-713
> Project: ServiceMix Components
> Issue Type: Bug
> Components: servicemix-http
> Affects Versions: servicemix-http-2008.01, servicemix-http-2009.01,
> servicemix-http-2009.02
> Environment: Windows XP, servicemix-http component 2009.02
> Reporter: Ryan Moquin
> Assignee: Jean-Baptiste Onofré
> Priority: Blocker
> Fix For: servicemix-http-2010.01
>
> Attachments: HttpConsumerEndpoint.java, HttpConsumerEndpoint.java
>
>
> In most of the servicemix-http component versions, including the latest,
> there is a variable called isSTFlow which is a class variable. This variable
> appears to be shared among all threads that access a deployed servicemix-http
> component. The problem with this is that isSTFlow is set by a certain
> request based upon the state of it's continuation when the exchange response
> is processed here:
> if (!cont.isPending()) {
> isSTFlow = true;
> System.out.println("isSTFlow set to true because continuation
> isn't pending.");
> } else {
> isSTFlow = false;
> System.out.println("isSTFlow set to false because continuation is
> pending.");
> If isSTFlow is set to true during that response.. all future requests that
> come in will then end up executing this code block on line 348:
> } else {
> String id =
> (String)request.getAttribute(MessageExchange.class.getName());
> System.out.println("STFlow was true, removing
> exchange with id: " + id);
> locks.remove(id);
> exchange = exchanges.remove(id);
>
> request.removeAttribute(MessageExchange.class.getName());
> }
> before the exchange associated with the request has had a chance to return.
> Once that exchange has returned, it can't be found, because it was removed
> and throws a timeout error. Once isSTFlow becomes true, the component hits a
> race condition where it checks isSTFlow for true before the async call has a
> chance to return and immediately times out the exchange. This variable needs
> to be localized for each specific request, not global to all requests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
