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: httpclient-user-
[EMAIL PROTECTED]
For additional commands, e-mail: httpclient-user-
[EMAIL PROTECTED]
------------------------------------------------------------------
--
-
To unsubscribe, e-mail: httpclient-user-
[EMAIL PROTECTED]
For additional commands, e-mail: httpclient-user-
[EMAIL PROTECTED]
