The only problem with setting reply timeouts is that for some of my remote actions can take a few milliseconds but others can take 30s or more... so a timeout of 30s doesn't make sense while if I set it too low the timeout will actually cut off the operation that is taking its time to complete operation. If there were a simple way of setting the read timeout on the socket I think that may work if its just an issue with the java nio sockets not returning some bytes.
Btw, I have seen an issue like this before when the person writing to the socket doesn't flush at the end and doesn't close it either, what happens is that nothing is going to make those bytes move down the pipe and the reader can be stuck forever. I'm going to have a look at the receiving end and the code that is there to see that appropriate flushing of the sockets are being done. Thank you for your response... Rodney. Brandon Chubb-2 wrote: > > On Thu, 10 Jan 2008, rodneygomes wrote: >> Not a single response in what half a year ? I still see this problem with >> the same client and it just keeps getting stuck on the socketRead0(), >> when I >> investigated the XMLRpc servers logs I don't see anything special all of >> the >> threads there are in the ThreadPool awaiting more work. If someone would >> at >> least give this some attention I could put together a sample application >> that hits this issue. > > I'm not sure how load affects this, but there's always the possibility of > the other side of the socket not cooperating, so I would use timeouts > on the socket. I don't think the LiteHttp has any timeout support in > 3.1, but it's easy enough to extend if you're determined to use that. > I had to duplicate some classes, though, because they weren't public, > and I wanted to make any extensions under our own source. We're still > using V2.0, though. > > By V3.1, there is some timeout options, though -- scan the source for > setConnectTimeout and setReadTimeout. The latter may be more appropriate > for you problem, but i think the connect timeout actually covers more > situations. > > Actually, now that I go grepping through the source: > > ./xmlrpc-3.1/client/src/main/java/org/apache/xmlrpc/client/XmlRpcLiteHttpTranspo > rt.java: if (config.getReplyTimeout() != 0) > ./xmlrpc-3.1/client/src/main/java/org/apache/xmlrpc/client/XmlRpcLiteHttpTranspo > rt.java: socket.setSoTimeout(config.getReplyTimeout()); > ./xmlrpc-3.1/common/src/main/java/org/apache/xmlrpc/common/XmlRpcHttpRequestConf > ig.java: int getConnectionTimeout(); > ./xmlrpc-3.1/common/src/main/java/org/apache/xmlrpc/common/XmlRpcHttpRequestConf > ig.java: int getReplyTimeout(); > > So it does look like some timeout support is in LiteHttp, you just need to > use it. > > -bc > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Client-getting-stuck-in-IO-layer...-tp12206458p14778406.html Sent from the Apache Xml-RPC - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
