Can anyone tell me what the "isSTFlow" variable does in the servicemix-http
component?  It's defined as:

private boolean isSTFlow;

but there isn't any javadoc that I see for it.

On Wed, Feb 3, 2010 at 9:55 AM, Jean-Baptiste Onofré <[email protected]>wrote:

> Hi Ryan,
>
> and thanks for the update.
>
> Have you raised any jira about this ?
>
> Thanks
> Regards
> JB
>
>
> Ryan Moquin wrote:
>
>> BTW - here is the stack trace for the other error I mentioned that seems
>> to
>> occur a lot with the other exception I mentioned below:
>>
>> java.lang.IllegalStateException: component is not owner when trying to set
>> error: java.lang.IllegalStateException: component is not owner
>>    at
>>
>> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.setError(MessageExchangeImpl.java:264)
>>    at
>>
>> org.apache.servicemix.common.endpoints.SimpleEndpoint.fail(SimpleEndpoint.java:93)
>>    at
>>
>> org.apache.servicemix.http.endpoints.HttpConsumerEndpoint.process(HttpConsumerEndpoint.java:395)
>>    at
>>
>> org.apache.servicemix.http.HttpBridgeServlet.service(HttpBridgeServlet.java:56)
>>    at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
>>    at
>> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502)
>>    at
>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:363)
>>    at
>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>>    at
>>
>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>>    at
>>
>> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
>>    at
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>>    at org.mortbay.jetty.Server.handle(Server.java:324)
>>    at
>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:534)
>>    at
>>
>> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:864)
>>    at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:533)
>>    at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:207)
>>    at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:403)
>>    at
>>
>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:409)
>>    at
>>
>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:522)
>> Caused by: java.lang.IllegalStateException: component is not owner
>>    at
>>
>> org.apache.servicemix.jbi.messaging.MessageExchangeImpl.setStatus(MessageExchangeImpl.java:251)
>>    at
>>
>> org.apache.servicemix.common.endpoints.SimpleEndpoint.done(SimpleEndpoint.java:84)
>>    at
>>
>> org.apache.servicemix.http.endpoints.HttpConsumerEndpoint.process(HttpConsumerEndpoint.java:393)
>>    ... 16 more
>>
>>
>> On Mon, Feb 1, 2010 at 8:49 PM, Ryan Moquin <[email protected]>
>> wrote:
>>
>>  Hi, I've been hitting an issue with the servicemix-http component.
>>>  Certain
>>> machines that we run a servicemix-http consumer endpoint on, seem to
>>> always
>>> have a problem with connection timeouts when a response is returned from
>>> the
>>> target SE.  The server is only being hit by a single user.  First off,
>>> here
>>> is the exception:
>>>
>>> *java.lang.Exception: HTTP request has timed out for exchange:
>>> ID:10.25.276.145-1267c593b09-8:22*
>>>
>>> *      at
>>>
>>> org.apache.servicemix.http.endpoints.HttpConsumerEndpoint.process(HttpConsumerEndpoint.java:242)
>>> *
>>>
>>> *      at
>>>
>>> org.apache.servicemix.common.AsyncBaseLifeCycle.doProcess(AsyncBaseLifeCycle.java:627)
>>> *
>>>
>>> *      at
>>>
>>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:598)
>>> *
>>>
>>> *      at
>>>
>>> org.apache.servicemix.common.AsyncBaseLifeCycle.onMessageExchange(AsyncBaseLifeCycle.java:535)
>>> *
>>>
>>> *      at
>>>
>>> org.apache.servicemix.common.SyncLifeCycleWrapper.onMessageExchange(SyncLifeCycleWrapper.java:60)
>>> *
>>>
>>> *      at
>>>
>>> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:623)
>>> *
>>>
>>> *      at
>>>
>>> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:172)
>>> *
>>>
>>> *      at
>>>
>>> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:168)
>>> *
>>>
>>> *      at
>>>
>>> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:134)
>>> *
>>>
>>> *      at
>>>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>>> *
>>>
>>> *      at
>>>
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>>> *
>>>
>>> *      at java.lang.Thread.run(Thread.java:619)*
>>>
>>> This exception is sometimes proceeded by a "Current Thread is not owner"
>>> exception in the servicemix-http.  There is no exception in our
>>> application
>>> that is causing this.  Sometimes when you refresh, the request and
>>> response
>>> will happen correctly, but then the next time you refresh is will start
>>> giving timeouts again.  This problem seem to occur with all of the 2009
>>> versions.  When I looked in the source code, it looks like the timeout
>>> happens when Servicemix attempts to resume the continuation in Jetty, but
>>> for some reason the resume() method returns false most of the time (I
>>> think
>>> false is the value when it can't resume it).  I can't seem to understand
>>> why
>>> this happens.  Does it sound like a bug?  I saw a post to the Jetty guys
>>> that Guillaume wrote saying that there were problems if a
>>> request-response
>>> happened too fast when a continuation was resumed before jetty had a
>>> chance
>>> to suspend it (if I remember correctly).  He wrote that a long time ago,
>>> but
>>> it almost sounds like that could be the cause here.  When it happens, the
>>> request/response is instant.  When it doesn't happen, the
>>> request-response
>>> cycle does seem slightly slower.
>>>
>>> This problem does seem to occur more often on certain machines than it
>>> does
>>> from other machines from my observation.  Anyone have any suggestions?
>>>
>>> Thanks!
>>> Ryan
>>>
>>>
>>>
>>>
>>

Reply via email to