servicemix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Moquin (JIRA)" <>
Subject [jira] Updated: (SM-1931) Threading problem in Servicemix-HTTP which renders the component unusable.
Date Fri, 05 Feb 2010 01:54:32 GMT


Ryan Moquin updated SM-1931:


Here is a version of this consumer endpoint that passes all of the servicemix-http unit tests
and also appears to work flawlessy for us.

> Threading problem in Servicemix-HTTP which renders the component unusable.
> --------------------------------------------------------------------------
>                 Key: SM-1931
>                 URL:
>             Project: ServiceMix
>          Issue Type: Bug
>          Components: servicemix-http
>    Affects Versions: 3.3.1
>         Environment: Windows XP, servicemix-http component 2009.02
>            Reporter: Ryan Moquin
>            Priority: Blocker
>         Attachments:
> 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.

View raw message