This is due to the fact that the 1.1 codebase does not specify a
read-timeout for the socket...thus all calls to read() have the potential to
block indefinitely -- even if the other end of the socket has disappeared.
If you look at the code for XmlRpcClientLite, you will see a method called
initConnection(). If you change the method to:
protected void initConnection () throws IOException
{
socket = new Socket (hostname, port);
socket.setSoTimeout( <put socket timeout here> );
output = new BufferedOutputStream (socket.getOutputStream());
input = new BufferedInputStream (socket.getInputStream ());
}
you will not have this "hanging" problem. Another option would be to use
Java 1.4 w/ the XmlRpcClient object & then specify timeouts for Sun's
default implementation of java.net.URLConnection. See the
"sun.net.client.defaultReadTimeout" property at
http://java.sun.com/j2se/1.4.2/docs/guide/net/properties.html
Hope this helps.
Michael
----- Original Message -----
From: "Janne Lindholm" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, August 25, 2003 11:52 PM
Subject: XmlRpcClient gets stuck
Hi,
we have an environment where multiple instances of XmlRpcClient in
different JVMs on our side call a single XML-RPC server on another host.
We have at least tens of thousands of calls per day, even hundreds of
thousands.
We are using Jakarta's XML-RPC 1.1.
Problem:
sometimes (rarely, maybe 5-10 times per day) our client gets stuck. Here's
the interesting part of thread dump:
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
- locked <e17b45e0> (a java.io.BufferedInputStream)
at
org.apache.xmlrpc.XmlRpcClientLite$HttpClient.readLine(XmlRpcClientLite.java
)
at
org.apache.xmlrpc.XmlRpcClientLite$HttpClient.sendRequest(XmlRpcClientLite.j
ava)
at
org.apache.xmlrpc.XmlRpcClientLite$LiteWorker.execute(XmlRpcClientLite.java)
What I mean with getting stuck is that just call never returns. We are
running this on live environment, so I don't have a possibility to check
if it really doesn't _ever_ return but so far we've seen situations of call
taking 10 hours and still not returning (at which point, we've rebooted
the server).
Any ideas? I know there is no timeouts in Jakarta's XML-RPC 1.1, but
really, is it normal that call can be blocked for this long? AFAIK, there
is no way to interrupt a call - is there?
BR,
Janne
