Infamous SocketException: Broken Pipe

Question

Hello,
As with many of the other users on this forum I have been plagued by the Broken Pipe SocketException, very rarely, which seems to essentially block on the java.net.SocketOutputStream.socketWrite0(Native Method) for quite a long time (presumably the length of some timeout) during a flush. It is also typically accompanied by a "java.net.SocketException: Connection timed out" on the socket itself.
I've read the many responses by EJP that this means:
"This is caused by writing to a connection when the other end has already closed it.
So you have a poorly defined or implemented application protocol."
My main question is: Is it normal for these exceptions to occur, and we just need to write some layer that handles this?
And a follow up: If so, would that layer be something along the lines of:
- a separate thread on the server for each output stream, and if this thread blocks during flush (for whatever reason), either:
- use a watchdog thread to close the output if some internal timeout has exceeded, or:
- just let Java's connection timeout eventually occur and let the output thread die
Or am I way off base here?
One more thing: Any other advice / best architectural practices / help regarding this problem / reading suggestions would be extremely appreciated.
Thanks.

Answer 1

EJP wrote:
Or else you are just streaming large amounts of data and the peer giving up is part oft the application protocol(for example, the peer is a browser and the user navigates away), in which case th correct action is to catch the exception and give up on the client.I believe this might be the case. The clients can (and typically do) receive the information I am sending. It is absolutely possible that they can navigate away during the transfer. It is fine for the purposes of the application to give up on this client. To give up on the client and not have flush() block my main thread, I would need a separate thread per client, for handling the outputstream, correct? ie. one for receive, another for send, per client.
There is something seriously wrong with your statement that the peer gets a connection timeout when this side gets a broken pipe. Connection timeout happens when creating a connection: in fact it happens instead of creating a connection. So there is no connection yet, so no peer at all, so it is impossible for the other end to be writing to the connection at all, because there is no connection and no other end. Do you mean a read timeout?I get:
ThreadID-1310 java.net.SocketException: Connection timed out
ThreadID-1310 java.net.SocketException: Broken pipe
On the server-side thread that holds the socket for this client. The Connection timed out happens from the Socket InputStream during a readByte(), Broken pipe happens from the Socket OutputStream during a flush().
Init code:
socket_ = serverSocket_.accept();
in_ = new DataInputStream(new BufferedInputStream(socket_.getInputStream()));
out_ = new DataOutputStream(new BufferedOutputStream(socket_.getOutputStream()));
mainThread.add(this); // the output main thread with some synchronization
start(); // the read thread belowReceive in the thread that throws Connection Timed out:
run() {
  while(running) {
    try {
      byte index = in_.readByte();
    } catch (SocketException e) {
      System.err.println(getId() + ": " + e);
}Send code in main thread that throws broken pipe:
    try {
      callingThread_.out_.flush()
    } catch (SocketException e) {
      System.err.println(callingThread_.getId() + ": " + e);
  }Both exceptions happen back to back. The Main thread keeps a back-pointer to the calling thread As you can see, both in_ and out_ are from the same socket on the original object. The user has absolutely been connected for a while before this occurs.
Thanks again for the insight.