Hi Henri,
> The socket timeout indicate the connection has been established but
> the reply couldn't be processed in time. How many Threads did you
> allow to the service ?
I'm not sure: I guess the default. How do I set the number of threads to
allow to the service? I'm using the WebServer class to expose my File
Manager server as an XML-RPC service. Is there any operations that will
allow me to up the amount of threads on the WebServer class?
Thanks for your help.
Cheers,
Chris
>
>
>
> 2006/5/10, Chris Mattmann <[EMAIL PROTECTED]>:
>> Guys,
>>
>> In followup to my prior message, here is the full stack trace of the error
>> that I am receiving:
>>
>> java.net.SocketTimeoutException: Read timed out
>> 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)
>> 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:11
>> 15)
>> at
>> org.apache.commons.httpclient.HttpMethodBase.readStatusLine(HttpMethodBase.j
>> ava:1832)
>> at
>> org.apache.commons.httpclient.HttpMethodBase.readResponse(HttpMethodBase.jav
>> a:1590)
>> at
>> org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:995
>> )
>> at
>> org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethod
>> Director.java:397)
>> at
>> org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDir
>> ector.java:170)
>> at
>> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:396)
>> at
>> org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
>> at
>> org.apache.xmlrpc.CommonsXmlRpcTransport.sendXmlRpc(CommonsXmlRpcTransport.j
>> ava:111)
>> at
>> org.apache.xmlrpc.XmlRpcClientWorker.execute(XmlRpcClientWorker.java:72)
>> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:194)
>> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:185)
>> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:178)
>> at
>> gov.nasa.jpl.oodt.cas.filemgr.system.XmlRpcFileManagerClient.ingestProduct(X
>> mlRpcFileManagerClient.java:493)
>>
>>
>> Line 493 in my XmlRpcFileManagerClient code is where I make the call to:
>>
>> productId = (String)fClient.execute("filemgr.ingestProduct",
>> argList);
>>
>>
>> Any ideas? Could it be a problem with the amount of allowed open sockets on
>> of my computer nodes? As I mentioned, the error doesn't manifest when I run
>> the File Manager client and server on the same powerful (4x Xeon processor,
>> head node in a cluster) host, only when they are run on different hosts (the
>> File Manager server on the powerful host, and the File Manager client on a
>> less powerful, dual CPU, compute node in my cluster).
>>
>> Thanks, again.
>>
>> Cheers,
>> Chris Mattmann
>>
>>
>>
>> On 5/9/06 9:05 PM, "Chris Mattmann" <[EMAIL PROTECTED]> wrote:
>>
>>> Hi guys,
>>>
>>> I'm trying to figure out a pretty frustrating problem I'm having with the
>>> 2.1-dev branch of xmlrpc. I have some simple code in a server component
>>> exposed through the XmlRpc WebServer class that does an ingest of a file and
>>> some metadata into an underlying catalog. The code looks something to the
>>> effect of:
>>>
>>> public class MyServer{
>>>
>>> public MyServer(int port){
>>> fWebServerPort = port;
>>>
>>> // start up the web server
>>> fWebServer = new WebServer(fWebServerPort);
>>> fWebServer.addHandler("filemgr", this);
>>> fWebServer.start();
>>> }
>>>
>>> public synchronized String ingestProduct(params...){
>>> //add catalog data
>>> //transfer file
>>> return fileId;
>>> }
>>>
>>> }
>>>
>>> In my client application, I call the ingestMethod, and I am noticing under
>>> some light stress (e.g., most likely between 30-40 communications,
>>> potentially simultaneous), that my MyServer class fails to respond to the
>>> client's invocation of it. My Client class looks like:
>>>
>>> public class MyClient{
>>> public XmlRpcClient fClient = null;
>>>
>>> public MyClient(URL serverUrl){
>>> //init fClient to point to the XmlRpcServer
>>> fClient = new XmlRpcClient(new URL(serverUrl));
>>> }
>>>
>>> public String ingestCall(params...){
>>> String productId = nulll;
>>> Vector argList = new Vector();
>>> argList.addAll(params);
>>> try {
>>> productId = (String)fClient.execute("filemgr.ingestProduct",
>>> argList);
>>> } catch (XmlRpcException e) {
>>> e.printStackTrace();
>>> throw new Exception(e.getMessage());
>>> } catch (IOException e) {
>>> e.printStackTrace();
>>> throw new Exception(e.getMessage());
>>> }
>>> }
>>>
>>> }
>>>
>>> The exception that is being thrown is the IOException, and it throws back:
>>>
>>> java.lang.Exception: Read timed out
>>>
>>> It throws back the regular Exception because I wrapped the IOException in
>>> the regular exception class. In any case, the method call to fClient.execute
>>> never returns and an exception is thrown. I've racked my brain trying to
>>> figure out why this happens. The weirder thing is, if I run the client and
>>> the server on the same machine, the error goes away. It's when I distribute
>>> the client and server to different machines that this error springs up.
>>> Could anyone suggest why this is happening, and furthermore, are there any
>>> ways to potentially fix this problem? I seem to only experience it under
>>> heavy stress to the Server class. Any help would be greatly appreciated.
>>>
>>> Thanks!
>>>
>>> Cheers,
>>> Chris
>>>
>>>
>>>
>>
>>
>>
______________________________________________
Chris A. Mattmann
[EMAIL PROTECTED]
Staff Member
Modeling and Data Management Systems Section (387)
Data Management Systems and Technologies Group
_________________________________________________
Jet Propulsion Laboratory Pasadena, CA
Office: 171-266B Mailstop: 171-246
Phone: 818-354-8810
_______________________________________________________
Disclaimer: The opinions presented within are my own and do not reflect
those of either NASA, JPL, or the California Institute of Technology.
