Skip to main content

"java.io.IOException: Error writing to server"

5 replies [Last post]
kirktrue
Offline
Joined: 2006-05-11

Hi all,

I'm consistently getting an error when communicating with a SOAP service via JAX-WS 2.1.1.

Here are some details when the error DOES occurs. It does happen when...

* ...using JAX-WS 2.1.1
* ...client and server are on the same subnet of a gigabit network
* ...multiple (in this case, 9) threads are hitting the same server at the same time

Here are some details when the error DOESN'T occur. It doesn't happen when...

* ...using Axis2 (the latest version)
* ...using JWSDP 2.0
* ...the client and server JVMs are on the same machine
* ...the client and server are on different networks (i.e. via VPN or on different subnets)
* ...executing iterations 2..N; only the first time it occurs
* ...only one client thread is used

Here is the exception:

Caused by: javax.xml.ws.WebServiceException: java.io.IOException: Error writing to server
at com.sun.xml.ws.transport.http.client.HttpClientTransport.checkResponseCode(HttpClientTransport.java:223)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:137)
at com.sun.xml.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:74)
at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:559)
at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:518)
at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:503)
at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:400)
at com.sun.xml.ws.client.Stub.process(Stub.java:235)
at com.sun.xml.ws.client.sei.SEIStub.doProcess(SEIStub.java:120)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:230)
at com.sun.xml.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:210)
at com.sun.xml.ws.client.sei.SEIStub.invoke(SEIStub.java:103)
at $Proxy34.documentProperties(Unknown Source)
at com.inxight.uima.LidAnnotator.callSdx(LidAnnotator.java:262)
at com.inxight.uima.LidAnnotator.process(LidAnnotator.java:122)
... 16 more
Caused by: java.io.IOException: Error writing to server
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:421)
at sun.net.www.protocol.http.HttpURLConnection.writeRequests(HttpURLConnection.java:433)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:959)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:367)
at com.sun.xml.ws.transport.http.client.HttpClientTransport.checkResponseCode(HttpClientTransport.java:186)
... 30 more

Note that from the server's perspective, there are no errors reported.

Any ideas of what could be causing this? We love JAX-WS because it uses (way) less memory than Axis2 and is a little faster too. Please let me know if there are any other details, tests, etc. I can provide.

Thanks!
Kirk

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kirktrue
Offline
Joined: 2006-05-11

> Looking at the JDK source code, the real cause of the
> error is masked by PrintStream. So what I'd suggest
> is to set break points on code like the following in
> java.io.PrintStream to see what is the real cause of
> the error.
> [code]
> catch (IOException x) {
> trouble = true;
> }
> [/code]
>
> If you find out, do let us know what was going on.

This only happens on a machine that I can't install an IDE on. So I tried jdb, was able to put a break point in the right place, and can tell you it's a java.net.SocketException, but that's it. The jdb dump, print, etc. command won't print the message of "x" because the JDK wasn't compiled with debug symbols.

Thanks,
Kirk

kirktrue
Offline
Joined: 2006-05-11

Hi Jitendra,

> * Can you see the output of netstat -a, if it gives any clues(like
> running out of sockets, resources etc)

I ran netstat -a 2 (re-poll every two seconds) but I didn't see anything stand out.

> * You can also play with these standard JDK system properties
> ||http.keepAlive=, |http.maxConnections=

I tried:

-Dhttp.keepAlive=false
-Dhttp.keepAlive=true
-Dhttp.maxConnections=1
-Dhttp.maxConnections=10
-Dhttp.keepAlive=false -Dhttp.maxConnections=1
-Dhttp.keepAlive=false -Dhttp.maxConnections=10
-Dhttp.keepAlive=true -Dhttp.maxConnections=1
-Dhttp.keepAlive=true -Dhttp.maxConnections=10

Unfortunately the error still occurs :(

> * There are some more minor fixes to Keep-Alive in 2.1.2(It is for
> doc/lit and body is mapped to void). You can give a try.

Do you have a link for the download?

> * Does this happen when client is running on someother machine(not in
> VMWare environment)

I misspoke. I saw that the machine was running the psuedo-network devices VMWare adds and came to the wrong conclusion. VMWare is running on the machine, but I'm not running my application on it. But just to be sure I uninstalled VMWare, but the problem still occurs.

Thanks,
Kirk

jitu
Offline
Joined: 2003-06-14

> Do you have a link for the download?

https://jax-ws.dev.java.net/2.1.2m1/
I doubt whether that would help. But you can try.

* You mentioned that you cannot install IDE on the machine. But you could remote debugging.
* Can you share the skeleton code of your client(Whether you create proxy per thread, or shared the same proxy across threads.).

kohsuke
Offline
Joined: 2003-06-09

This is coming from the JDK network layer, so it's bit surprising that it doesn't happen with Axis2, JWSDP 2.0, etc.

Looking at the JDK source code, the real cause of the error is masked by PrintStream. So what I'd suggest is to set break points on code like the following in java.io.PrintStream to see what is the real cause of the error.
[code]
catch (IOException x) {
trouble = true;
}
[/code]

If you find out, do let us know what was going on. This seems like a very interesting problem.

jitu
Offline
Joined: 2003-06-14

I am posting the my response, that was posted on the users alias. JDK doesn't give any useful info here. Follow Kohsuke's suggestion, let us know.

* Can you see the output of netstat -a, if it gives any clues(like running out of sockets, resources etc) * You can also play with these standard JDK system properties http.keepAlive=, |http.maxConnections=
* There are some more minor fixes to Keep-Alive in 2.1.2(It is for doc/lit and body is mapped to void). You can give a try.
* Does this happen when client is running on someother machine(not in VMWare environment)