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 > [EMAIL PROTECTED] > > "Intelligent testing made convenient" > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
