hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Lockup in XFire
Date Mon, 07 Aug 2006 22:18:22 GMT
On Mon, 2006-08-07 at 14:40 -0700, Patrick Lightbody wrote:
> Oleg,
> Sure, I understand that the issue is due to a native timeout - but  
> the question is: why?
> 

(1) The only reason for a native socket read to block indefinitely is
the SO_TIMEOUT value set to zero. Does XFire explicitly set the socket
timeout value to a positive value?

(2) org.apache.commons.httpclient.HttpMethodBase writeRequest
100 (continue) read timeout. Resume sending the request

This message is logged when the target server fails to properly respond
to the "Expect: 100-continue" handshake. When the handshake is activated
HttpClient sends the request header containing the "Expect:
100-continue" directive prior to sending the request body and expects
the target server to respond with status code 100 indicating that it is
okay to proceed with sending the request content. Apparently the server
has issues with the "Expect: 100-continue" handshake or simply locks up
while processing the request header.

Hope this helps.

Oleg

> Like I reported in my initial email, subsequent requests in other  
> threads (coming from test.jsp) work fine.
> 
> Patrick
> 
> Patrick Lightbody
> Autoriginate, Inc.
> 503-488-5402
> http://www.autoriginate.com
> patrick@autoriginate.com
> 
> "Intelligent testing made convenient"
> 
> 
> On Aug 7, 2006, at 2:34 PM, Oleg Kalnichevski wrote:
> 
> > On Mon, 2006-08-07 at 12:29 -0700, Patrick Lightbody wrote:
> >> I've tried using XFire 1.1.1 and 1.2-RC, combined with HttpClient 3.0
> >> and 3.1-alpha1. I get the same result, outlined below, which causes a
> >> complete lockup of a thread. I can't figure out what would cause  
> >> this.
> >>
> >> When making a call via XFire (ClientService.getAppLog()), the current
> >> thread locks up just after printing the following out in the logs:
> >>
> >> org.apache.commons.httpclient.HttpMethodBase writeRequest
> >> 100 (continue) read timeout. Resume sending the request
> >>
> >> I see that this log comes from an InterruptedIOException here:
> >>
> >> http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/
> >> httpclient/HttpMethodBase.html#2004
> >>
> >> The stack dump of the locked thread is:
> >>
> >> "Thread-62" daemon prio=1 tid=0x082602c0 nid=0x51ca runnable
> >> [0x79926000..0x79926e30]
> >
> > Patrick,
> > As you can see the thread gets blocked in the native socket read  
> > method,
> > so this is very unlikely to be a threading dead-lock in the HttpClient
> > code. Most likely the socket read operation blocks indefinitely  
> > because
> > socket timeout is not set (SO_TIMEOUT value is set to zero).
> >
> > Hope this helps
> >
> > Oleg
> >
> >
> >>         at java.net.SocketInputStream.socketRead0(Native Method)
> >>         at java.net.SocketInputStream.read(SocketInputStream.java: 
> >> 129)
> >>         at java.io.BufferedInputStream.fill(BufferedInputStream.java:
> >> 218)
> >>         at java.io.BufferedInputStream.read(BufferedInputStream.java:
> >> 235)
> >>         - locked <0x830328c8> (a java.io.BufferedInputStream)
> >>         at org.apache.commons.httpclient.HttpParser.readRawLine
> >> (HttpParser.java:77)
> >>         at org.apache.commons.httpclient.HttpParser.readLine
> >> (HttpParser.java:105)
> >>         at org.apache.commons.httpclient.HttpConnection.readLine
> >> (HttpConnection.java:1115)
> >>         at
> >> org.apache.commons.httpclient.MultiThreadedHttpConnectionManager
> >> $HttpConnectionAdapter.readLine
> >> (MultiThreadedHttpConnectionManager.java:1373)
> >>         at  
> >> org.apache.commons.httpclient.HttpMethodBase.readStatusLine
> >> (HttpMethodBase.java:1832)
> >>         at org.apache.commons.httpclient.HttpMethodBase.readResponse
> >> (HttpMethodBase.java:1590)
> >>         at org.apache.commons.httpclient.HttpMethodBase.execute
> >> (HttpMethodBase.java:995)
> >>         at
> >> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry
> >> (HttpMethodDirector.java:397)
> >>         at
> >> org.apache.commons.httpclient.HttpMethodDirector.executeMethod
> >> (HttpMethodDirector.java:170)
> >>         at org.apache.commons.httpclient.HttpClient.executeMethod
> >> (HttpClient.java:396)
> >>         at
> >> org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send
> >> (CommonsHttpMessageSender.java:226)
> >>         at  
> >> org.codehaus.xfire.transport.http.HttpChannel.sendViaClient
> >> (HttpChannel.java:118)
> >>         at org.codehaus.xfire.transport.http.HttpChannel.send
> >> (HttpChannel.java:48)
> >>         at org.codehaus.xfire.handler.OutMessageSender.invoke
> >> (OutMessageSender.java:26)
> >>         at org.codehaus.xfire.handler.HandlerPipeline.invoke
> >> (HandlerPipeline.java:130)
> >>         at org.codehaus.xfire.client.Invocation.invoke
> >> (Invocation.java:75)
> >>         at org.codehaus.xfire.client.Client.invoke(Client.java:335)
> >>         at org.codehaus.xfire.client.XFireProxy.handleRequest
> >> (XFireProxy.java:77)
> >>         at org.codehaus.xfire.client.XFireProxy.invoke
> >> (XFireProxy.java:57)
> >>         at $Proxy5.getAppLog(Unknown Source)
> >>         at com.hostedqa.model.TestContextImpl.dispose
> >> (TestContextImpl.java:83)
> >>         at com.hostedqa.model.Suite.playback(Suite.java:85)
> >>         at com.hostedqa.service.PlaybackService.runTest
> >> (PlaybackService.java:83)
> >>         at com.hostedqa.service.PlaybackService.playSuite
> >> (PlaybackService.java:48)
> >>         at com.hostedqa.action.project.suite.PlayAction$1.run
> >> (PlayAction.java:25)
> >>         at java.lang.Thread.run(Thread.java:595)
> >>
> >> What's very weird is that I am able to drop a JSP (test.jsp) that
> >> makes the exact same call and it completes just fine. This tells me
> >> that there is something environmental about _this_ thread that causes
> >> HttpClient to do this. The call alone is not the issue.
> >>
> >> Also, I might add that the XFire call never makes it to the other end
> >> (ClientServiceImpl), as I have a print line there that never gets
> >> invoked. I ran a stack dump on the other side as well, and nothing
> >> stood out (though it is possible part of the request made it through
> >> to XFire's Servlet, and then broke and was no longer in the active
> >> thread dump by the time I forced the dump).
> >>
> >> Finally, this request is running over HTTP. I'd really like to figure
> >> out:
> >>
> >> 1) What that log from HttpMethodBase.writeRequest() is all about
> >> 2) Why there would be a perpetual "pause" in the native method, but
> >> no actual visible deadlock.
> >> 3) How to fix this :)
> >>
> >> Patrick
> >>
> >> Patrick Lightbody
> >> Autoriginate, Inc.
> >> 503-488-5402
> >> http://www.autoriginate.com
> >> patrick@autoriginate.com
> >>
> >> "Intelligent testing made convenient"
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: httpclient-user- 
> >> unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: httpclient-user- 
> >> help@jakarta.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user- 
> > help@jakarta.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


Mime
View raw message