Strange Socket problem?

K

Knute Johnson

Since upgrading to 1.6 I have seen on occasion a socket disconnect that
isn't detected by the client end. No exception is thrown and the stream
I/O stays blocked. The host end definitely shows the connection closed.
I can't reproduce it which is going to be a problem if I want to file
a bug report. Has anybody else seen this since upgrading to 1.6?
 
T

Tom Hawtin

Knute said:
Since upgrading to 1.6 I have seen on occasion a socket disconnect that
isn't detected by the client end. No exception is thrown and the stream
I/O stays blocked. The host end definitely shows the connection closed.
I can't reproduce it which is going to be a problem if I want to file a
bug report. Has anybody else seen this since upgrading to 1.6?

Are you sure it's not just coincidental that the occasional connection
drops after you upgraded to 1.6? If there's a network problem it often
wont show until sometime after a write from that socket, but that's
nothing to do with Java.

Tom Hawtin
 
K

Knute Johnson

Tom said:
Are you sure it's not just coincidental that the occasional connection
drops after you upgraded to 1.6? If there's a network problem it often
wont show until sometime after a write from that socket, but that's
nothing to do with Java.

Tom Hawtin

I've got some software in the field that is now occasionally hanging
when it didn't before. Although that problem is newer than the change
to 1.6. I'm working on another program and the client in that pair has
hung a few times on me while the host has definitely shown a disconnect.
And it is very possible that it is all coincidental. The client end
that has missed the disconnect in both cases has only been reading.
Reads have always been a reliable way to detect disconnects in the past.

I have put a timer into the software in the field to check to make sure
that the read thread has terminated. We had an actual failure this
morning and it was not corrected because the read thread did not
terminate even when the socket was closed. No exception was thrown.
This program is very complicated though and it is quite possible that my
fix was not correct. I've got a new fix going in tonight (why is it
that it always has to be late at night :).

Oh and one more tidbit is that on the new project I'm working on the
hang occurred with the host and client on the same machine.

All the computers are running Windows XP which just adds to the
entertainment value.

Thanks very much for your interest.
 
M

Matt Atterbury

Knute Johnson said:
Oh and one more tidbit is that on the new project I'm working on the
hang occurred with the host and client on the same machine.
:

This alone makes me suspect it's the application, the fact that it's XP
notwithstanding (despite my misgivings, I would trust the average M$
system programmer before the average application programmer, just :)

Would it be difficult to introduce bidirectional heartbeats between
the server and the client, with timeouts?

m.
 
T

Tom Hawtin

Knute said:
Reads have always been a reliable way to detect disconnects in the past.

Reads generally aren't great. They generate no traffic, so you wouldn't
even expect the remote end to respond. You might get an ICMP no route to
host message if you are lucky. What you can do is send some form of NOP
periodically. (Can't remember if flush will actually send an empty packet.)
Oh and one more tidbit is that on the new project I'm working on the
hang occurred with the host and client on the same machine.

So probably not a network failure then.

Having a brief look at the code closing a socket close the file
descriptor which then presumably that closes the streams. The path is
direct, so I can't claim out of hand that it is your fault...

Tom Hawtin
 
K

Knute Johnson

Tom said:
Reads generally aren't great. They generate no traffic, so you wouldn't
even expect the remote end to respond. You might get an ICMP no route to
host message if you are lucky. What you can do is send some form of NOP
periodically. (Can't remember if flush will actually send an empty packet.)


So probably not a network failure then.

Having a brief look at the code closing a socket close the file
descriptor which then presumably that closes the streams. The path is
direct, so I can't claim out of hand that it is your fault...

Tom Hawtin

Thanks Matt and Tom. I hate it when I have a lot of coincidental
happenings. Makes me start to think that this stuff runs on voodoo.

Two of my three programs in the field locked up again this morning so
I've got another fix to put in tonight. One of the threads only reads
so I'm going to try closing its socket instead of the output stream. I
reorganized some other code so maybe I'll get it cured. I know that the
server end has been having some problems as this code worked flawlessly
for almost a year before it started giving me fits.

Thanks again,
 
K

Knute Johnson

More in the continuing saga. It appears now that I'm really having a
problem getting the BufferedInputStream.read() to throw an exception
when the stream is closed. I've tried closing the input stream and the
socket and it appears that neither is causing the exception to be thrown.
 
E

Esmond Pitt

Knute said:
More in the continuing saga. It appears now that I'm really having a
problem getting the BufferedInputStream.read() to throw an exception
when the stream is closed. I've tried closing the input stream and the
socket and it appears that neither is causing the exception to be thrown.

Are you closing the socket from another thread in the same JVM while a
thread is blocked in the read? This isn't specified to work: it works
on some platforms, not all. That's why
java.nio.channels.InterruptibleChannel was introduced. IOW it works on
Sockets that you get from SocketChannels but not (necessarily) on pure
java.net.Sockets.
 
K

Knute Johnson

Esmond said:
Are you closing the socket from another thread in the same JVM while a
thread is blocked in the read? This isn't specified to work: it works
on some platforms, not all. That's why
java.nio.channels.InterruptibleChannel was introduced. IOW it works on
Sockets that you get from SocketChannels but not (necessarily) on pure
java.net.Sockets.

Yes. I'm not sure how you could do it from the same thread since it is
blocked. Where is it specified not to work?

Thanks,
 
E

Esmond Pitt

Knute said:
Yes. I'm not sure how you could do it from the same thread since it is
blocked. Where is it specified not to work?

It's not specified that it does work unless the object implements
InterruptibleChannel.

Use a read timeout of a couple of minutes and check a flag, or
Thread.isInterrupted(), every time it triggers.
 
G

Graham

More in the continuing saga. It appears now that I'm really having a
problem getting the BufferedInputStream.read() to throw an exception
when the stream is closed. I've tried closing the input stream and the
socket and it appears that neither is causing the exception to be thrown.

I've had problems with BufferedInputStream.read() on Windows XP
machines with the problem you describe. Although a BufferedInputStream
will not throw an exception, I seem to remember that it will reliably
return a -1 to indicate that the end of the stream has been reached
after the server has closed the socket (and if you perform another
read it seems to block indefinitely).

Are you definitely checking for this scenario? It was a while ago and
unfortunately I don't have access to a Windows machine at the moment
so I can't confirm it, but thought I would throw it in as a suggestion
anyway.
 
K

Knute Johnson

Esmond said:
It's not specified that it does work unless the object implements
InterruptibleChannel.

Use a read timeout of a couple of minutes and check a flag, or
Thread.isInterrupted(), every time it triggers.

While that may be the case for NIO I don't think that is true for stream
I/O. From the docs;

Socket.close()

"Any thread currently blocked in an I/O operation upon this socket will
throw a SocketException.

....

Closing this socket will also close the socket's InputStream and
OutputStream"

I don't know how you could call Socket.close() from the blocked thread
so it would have to work from another.
 
K

Knute Johnson

Graham said:
I've had problems with BufferedInputStream.read() on Windows XP
machines with the problem you describe. Although a BufferedInputStream
will not throw an exception, I seem to remember that it will reliably
return a -1 to indicate that the end of the stream has been reached
after the server has closed the socket (and if you perform another
read it seems to block indefinitely).

Are you definitely checking for this scenario? It was a while ago and
unfortunately I don't have access to a Windows machine at the moment
so I can't confirm it, but thought I would throw it in as a suggestion
anyway.

Graham:

Thanks for the idea but yes I am checking for end of stream. I'm going
to try some tests with that though on XP and Linux to see if there are
differences.
 
K

Knute Johnson

Esmond said:
When you've tried this let us know.

Then code has had read timeouts from the beginning. They work fine if
there is a connection but when it messes up it never times out.
 
E

Esmond Pitt

Knute said:
Then code has had read timeouts from the beginning. They work fine if
there is a connection but when it messes up it never times out.

Sorry, I'm not getting this. How are you detecting the lost connection
if not via a read timeout?
 
K

Knute Johnson

Esmond said:
Sorry, I'm not getting this. How are you detecting the lost connection
if not via a read timeout?

That's the point exactly. It isn't being detected. I put an alligator
in to attempt to close the connection if it hangs. The alligator closes
the socket. If it were working correctly, the blocked read would either
return -1 or throw an IOException when the other end closes. It
doesn't, that's what I've been wrestling with.
 
E

Esmond Pitt

Knute said:
That's the point exactly. It isn't being detected. I put an alligator
in to attempt to close the connection if it hangs.

'If it hangs' meaning what? Sorry, I'm not getting this.

Anyway the read timeout should throw a SocketTimeoutException. I've
never seen it not work. What platform?
 
K

Knute Johnson

Esmond said:
'If it hangs' meaning what? Sorry, I'm not getting this.

Anyway the read timeout should throw a SocketTimeoutException. I've
never seen it not work. What platform?

The host end disconnects but the client end does not detect the
disconnection. I know the complete data transfer will only last a few
seconds so I wrote an alligator that closes the client socket to end the
thread. But when this problem happens, closing the socket does not
throw an exception or cause the read() to return and it will not
timeout. The thread is hung.

Platform is Windows XP.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top