Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / July 2007

Tip: Looking for answers? Try searching our database.

Hang on socket close after connection reset or connection timed out

Thread view: 
Helene Unterwieser - 27 Jun 2007 19:45 GMT
Hi all,

i have a rather nasty problem here and the situation is pretty critical
so please help wit anything that comes to your mind.
There is a thread with a server socket which accepts a connection and
spawns another thread with the created client socket. The connection
works for some time without problems. Then a IOException is thrown when
writing to the client socket, either "Connection reset" or "Connection
timed out". To handle the broken connection, the client socket should
then be closed by the thread but hangs in the close method forever.
So the question is how can a "Connection reset" or "Connection timed
out" be reproduced when sending data? If this is possible maybe the hang
on close can be reproduced.
bencoe@gmail.com - 27 Jun 2007 20:34 GMT
On Jun 27, 2:45 pm, Helene Unterwieser <h.unterwie...@chello.at>
wrote:
> Hi all,
>
[quoted text clipped - 9 lines]
> out" be reproduced when sending data? If this is possible maybe the hang
> on close can be reproduced.

Sounds like you're hitting a blocking situation with the client
socket... One way around this is using the method.

Socket.setSoTimeout(int timeout)

This sets a maximum wait time on a socket before an exception is
automatically thrown, this can be used in situations such as the one
you're describing to make sure that you don't block on a socket
indefinitely.

-----
Ben
http://www.plink-search.com
Esmond Pitt - 29 Jun 2007 05:23 GMT
>>So the question is how can a "Connection reset" or "Connection timed
>>out" be reproduced when sending data? If this is possible maybe the hang
>>on close can be reproduced.
>
> Sounds like you're hitting a blocking situation with the client
> socket...

No it doesn't.

> One way around this is using the method.
> Socket.setSoTimeout(int timeout)
[quoted text clipped - 3 lines]
> you're describing to make sure that you don't block on a socket
> indefinitely.

That only applies to read operations, not to write or close operations.
It has no relevance to the question.

'Connection reset' happens when you write data to a connection when the
other end is already closed.

You can't get 'connection timed out' from a socket accepted by a server.
It is impossible. You also can't get it when either reading or writing
in the client. You can only get it *in the client* when constructing or
connecting the socket.

A close of a socket can only block if:

(a) you are closing the output stream, it is buffered, it hasn't been
flushed, the client is behind with its reads so its socket receive
buffer is full, and your socket send buffer is full; *or*

(b) you have set a large positive linger timeout - don't mess with this
setting, *or*

(c) You are closing from another thread and you encounter Java
synchronization.
Knute Johnson - 29 Jun 2007 05:57 GMT
> 'Connection reset' happens when you write data to a connection when the
> other end is already closed.

Or if the reading end is blocked and the writing end is closed.

Signature

Knute Johnson
email s/nospam/knute/

Esmond Pitt - 29 Jun 2007 10:04 GMT
> Or if the reading end is blocked and the writing end is closed.

'Connection reset' is only encountered by the writing end. If the
writing end was closed it would get 'socket closed'.
Knute Johnson - 29 Jun 2007 17:12 GMT
>> Or if the reading end is blocked and the writing end is closed.
>
> 'Connection reset' is only encountered by the writing end. If the
> writing end was closed it would get 'socket closed'.

I hate to be disagreeable but that is not what I am getting.  On the app
I am currently working on, if the reading end is blocked on read and the
writing end is closed, I get a connection reset.

C:\com\knutejohnson\tsn>java -jar Client.jar
java.net.SocketException: Connection reset
        at java.net.SocketInputStream.read(Unknown Source)
        at java.net.SocketInputStream.read(Unknown Source)
        at java.io.ObjectInputStream$PeekInputStream.peek(Unknown Source)
        at java.io.ObjectInputStream$BlockDataInputStream.peek(Unknown
Source)
        at
java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Sourc
e)
        at java.io.ObjectInputStream.readObject0(Unknown Source)
        at java.io.ObjectInputStream.readObject(Unknown Source)
        at com.knutejohnson.tsn.Client.run(Client.java:73)
        at java.lang.Thread.run(Unknown Source)

Signature

Knute Johnson
email s/nospam/knute/

Esmond Pitt - 01 Jul 2007 09:31 GMT
> ... that is not what I am getting.  On the app
> I am currently working on, if the reading end is blocked on read and the
> writing end is closed, I get a connection reset.

That can only be because you have also done a write from this end that
got the reset reply because the other end was closed. There's no wire
protocol associated with a TCP read operation, so there is no way it can
provoke a reset.
Knute Johnson - 01 Jul 2007 18:31 GMT
>> ... that is not what I am getting.  On the app I am currently working
>> on, if the reading end is blocked on read and the writing end is
[quoted text clipped - 4 lines]
> protocol associated with a TCP read operation, so there is no way it can
> provoke a reset.

You want to see the code, there isn't a write in it?

Signature

Knute Johnson
email s/nospam/knute/

Esmond Pitt - 02 Jul 2007 02:46 GMT
> You want to see the code, there isn't a write in it?

Sure, if you like. Send it to me privately via
http://www.telekinesis.com.au/wipv3_6/people.A21. There are other
explanations for ECONNRESET but they usually emanate from the other end
and they don't have anything to do with read blocks. Does the writing
end fiddle with SO_LINGER? or is it MS IIS  by any chance (which does)?

There's also the local condition 'software caused connection abort',
WSAECONNABORTED (10053), but that's not what's happenin here. For more
info on that see
http://forum.java.sun.com/thread.jspa?forumID=11&threadID=748677.
Knute Johnson - 02 Jul 2007 05:12 GMT
>> You want to see the code, there isn't a write in it?
>
[quoted text clipped - 8 lines]
> info on that see
> http://forum.java.sun.com/thread.jspa?forumID=11&threadID=748677.

Here is a really simple example.  Run s then c.  If you don't get a
java.net.SocketExcepion: Connection reset I'll eat my hat (or a
reasonable facsimile like a cheeseburger).  I'm not being rude but I
won't be able to reply for a week to 10 days.  Sorry.

import java.io.*;
import java.net.*;

public class s {
    public static void main(String[] args) throws Exception {
        ServerSocket ss = new ServerSocket(1111);
        Socket s = ss.accept();
        Thread.sleep(1000);
    }
}

import java.io.*;
import java.net.*;

public class c {
    public static void main(String[] args) {
        try {
            Socket s = new Socket("127.0.0.1",1111);
            System.out.println(
             "connected to: " + s.getInetAddress().getHostAddress());
            InputStream is = s.getInputStream();
            is.read();
        } catch (Exception e) {
            System.out.println(e);
        }
    }
}

Signature

Knute Johnson
email s/nospam/knute/

Esmond Pitt - 02 Jul 2007 08:21 GMT
> Here is a really simple example.  Run s then c.  If you don't get a
> java.net.SocketExcepion: Connection reset I'll eat my hat (or a
> reasonable facsimile like a cheeseburger).

My apologies, you are correct and I have forgotten this for the Nth time
this year, so I will eat the hat (hold the cheeesburger). Exiting a JVM
or indeed any Unix or Windows process causes a TCP RST to be issued on
all sockets that are still open. Somewhat counter-intuitive behaviour
IMO, you would expect the OS to close the fd and therefore TCP to issue
a FIN. Obviously TCP gets in first somehow.

I don't know that that has any bearing on the OP's problem though?
Gordon Beaton - 02 Jul 2007 08:51 GMT
> Exiting a JVM or indeed any Unix or Windows process causes a TCP RST
> to be issued on all sockets that are still open. Somewhat
> counter-intuitive behaviour IMO, you would expect the OS to close
> the fd and therefore TCP to issue a FIN.

On "not Unix" Linux (Fedora 6) using JDK 1.6, in.read() returned -1
(EOF) and no exception was raised when I tested the posted example. I
see with Wireshark that FIN was sent, not RST. Got the same results on
Solaris 8.

Maybe its just a Windows thing?

/gordon

--
Esmond Pitt - 03 Jul 2007 00:27 GMT
> Maybe its just a Windows thing?

That would figure ...
bencoe@gmail.com - 29 Jun 2007 06:35 GMT
On Jun 29, 12:23 am, Esmond Pitt <esmond.p...@nospam.bigpond.com>
wrote:
> ben...@gmail.com wrote:
> >>So the question is how can a "Connection reset" or "Connection timed
[quoted text clipped - 5 lines]
>
> No it doesn't.

Based on the limited information provided by Helene, I think there is
a good chance that the client is blocking on a read operation. Perhaps
you could clarify a bit Helene, or post the chunk of code that appears
to not be exiting? This would be better than arguing, without complete
information.

Ben.
Esmond Pitt - 29 Jun 2007 10:03 GMT
> Based on the limited information provided by Helene, I think there is
> a good chance that the client is blocking on a read operation.

I'm sorry but this doesn't make sense. If the client was blocking on a
read operation, (a) the connection would still be open, so there is no
reason for 'connection reset', and (b) the flush and close by the sender
would be able to write and complete and not block.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.