5

This is basically the picture: I have a server and a client (operating through localhost). Server creates a clientthread for each connection. this new thread blocks on read waiting for messages from client. At will, i can deactivate the server through the GUI, which sends (from a main thread) "disconnect" to the client, and then closes the output stream, to wake up the blocked clientthread, which in turn finishes up by closing the socket (I believe this closing is unnecessary after closing outputstream but anyway).

Client side: After connection request, it sleeps 10 seconds, writes a disconnect message and reads the answer char by char.

The problem:

After deactivating the server within that 10 second client sleep time, client reads the "disconnect" message correctly from the server. However, If I just add a dummy print for each char read (inside the while loop), the result of the final read is varying. Sometimes it will read the server's "disconnect" correctly, sometimes it will read "disco", or a similar variation, and throw this exception:

"Java exception : "Software caused connection abort: recv failed"

Any suggestions as to why adding a few prints creates this result? I would assume having a closed socket on the other end wouldn't have an effect on reading the message. The other threads I found about recv errors mentioned timeouts, which I'm guessing shouldn't really be happening when using localhost?

Bimp
  • 494
  • 2
  • 5
  • 14
  • If the "timeouts" mentioned on the other answers refer to write timeouts, then indeed it can probably be considered a duplicate – Bimp Dec 09 '11 at 13:33

2 Answers2

1

The error occurs because the other end has disconnected and your write has failed. If you read quickly enough, it hasn't determined the connection has been lost.

There are ways to avoid this error, but the simplest thing to do is to ignore it

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • 1
    "my write has failed" meaning the client's write? – Bimp Dec 09 '11 at 13:27
  • Yes. The write was accepted by the OS because at that time it don't know the server had disconnected. After the server determines the server has disconnect, it can give you this error. You could read the end of stream before or after this is determined. – Peter Lawrey Dec 09 '11 at 13:32
  • 2
    A way around this is to request a disconnect from the other end and only close when you get a disconnect response. AT this point, both ends know the connection is to be closed and no messages written will be lost. However, you must also handle an ungraceful shut down of the connection in any case. – Peter Lawrey Dec 09 '11 at 13:36
  • Yes, that would be a good way to solve it, unfortunately I can't normally manage the client side (in the example i'm only managing it to find ways it could go wrong). – Bimp Dec 09 '11 at 13:44
  • You could have the server send the disconnect, and wait for the client to honour the request and only then close the connection. (Or timeout and close it if it still does not close it) – Peter Lawrey Dec 09 '11 at 13:46
  • Not sure what you mean by "honour the request". What I meant above is, I'm not the one handling the client code, so I can't make it send a verification for the server's disconnect. – Bimp Dec 09 '11 at 14:17
  • You can send it a disconnect message and wait for the client to close the connection first. When you get an exception trying to read (or length < 0) from it, you know the client has closed the connection. – Peter Lawrey Dec 09 '11 at 14:41
-2

Recently saw this error caused by a lack of proxy set in JBoss config (I.e. standalone.xml). Add a proxy to your system properties if necessary - you can check if you need them by calling the web service with SoapUI.

J. Titor
  • 11
  • 2