Hang on socket close after connection reset or connection timed out

Discussion in 'Java' started by Helene Unterwieser, Jun 27, 2007.

  1. 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.
    Helene Unterwieser, Jun 27, 2007
    #1
    1. Advertising

  2. Helene Unterwieser

    Guest

    On Jun 27, 2:45 pm, Helene Unterwieser <>
    wrote:
    > 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.


    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
    , Jun 27, 2007
    #2
    1. Advertising

  3. Helene Unterwieser

    Esmond Pitt Guest

    Re: Hang on socket close after connection reset or connection timedout

    wrote:
    >>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)
    >
    > 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.


    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.
    Esmond Pitt, Jun 29, 2007
    #3
  4. Re: Hang on socket close after connection reset or connection timedout

    Esmond Pitt wrote:
    > '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.

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jun 29, 2007
    #4
  5. Helene Unterwieser

    Guest

    On Jun 29, 12:23 am, Esmond Pitt <>
    wrote:
    > wrote:
    > >>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.


    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.
    , Jun 29, 2007
    #5
  6. Helene Unterwieser

    Esmond Pitt Guest

    Re: Hang on socket close after connection reset or connection timedout

    wrote:
    > 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.
    Esmond Pitt, Jun 29, 2007
    #6
  7. Helene Unterwieser

    Esmond Pitt Guest

    Re: Hang on socket close after connection reset or connection timedout

    Knute Johnson wrote:

    > 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'.
    Esmond Pitt, Jun 29, 2007
    #7
  8. Re: Hang on socket close after connection reset or connection timedout

    Esmond Pitt wrote:
    > Knute Johnson wrote:
    >
    >> 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)

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jun 29, 2007
    #8
  9. Helene Unterwieser

    Esmond Pitt Guest

    Re: Hang on socket close after connection reset or connection timedout

    Knute Johnson wrote:
    > ... 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.
    Esmond Pitt, Jul 1, 2007
    #9
  10. Re: Hang on socket close after connection reset or connection timedout

    Esmond Pitt wrote:
    > Knute Johnson wrote:
    >> ... 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.


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

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jul 1, 2007
    #10
  11. Helene Unterwieser

    Esmond Pitt Guest

    Re: Hang on socket close after connection reset or connection timedout

    Knute Johnson wrote:
    > 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.
    Esmond Pitt, Jul 2, 2007
    #11
  12. Re: Hang on socket close after connection reset or connection timedout

    Esmond Pitt wrote:
    > Knute Johnson wrote:
    >> 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.


    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);
    }
    }
    }

    --

    Knute Johnson
    email s/nospam/knute/
    Knute Johnson, Jul 2, 2007
    #12
  13. Helene Unterwieser

    Esmond Pitt Guest

    Re: Hang on socket close after connection reset or connection timedout

    Knute Johnson wrote:

    > 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?
    Esmond Pitt, Jul 2, 2007
    #13
  14. On Mon, 02 Jul 2007 07:21:25 GMT, Esmond Pitt wrote:
    > 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

    --
    Gordon Beaton, Jul 2, 2007
    #14
  15. Helene Unterwieser

    Esmond Pitt Guest

    Re: Hang on socket close after connection reset or connection timedout

    > Maybe its just a Windows thing?

    That would figure ...
    Esmond Pitt, Jul 3, 2007
    #15
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve
    Replies:
    0
    Views:
    5,308
    Steve
    Jul 1, 2003
  2. =?Utf-8?B?QWxleCBQYXBhZGltb3VsaXM=?=

    HttpWebRequest Operation Has Timed Out After Numerous Requests

    =?Utf-8?B?QWxleCBQYXBhZGltb3VsaXM=?=, Jan 29, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    531
    =?Utf-8?B?QWxleCBQYXBhZGltb3VsaXM=?=
    Jan 29, 2006
  3. =?Utf-8?B?QWxleCBQYXBhZGltb3VsaXM=?=

    HttpWebRequest Operation Has Timed Out After Numerous Requests #2

    =?Utf-8?B?QWxleCBQYXBhZGltb3VsaXM=?=, Jan 30, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    2,488
    =?Utf-8?B?QWxleCBQYXBhZGltb3VsaXM=?=
    Jan 30, 2006
  4. JuHui
    Replies:
    3
    Views:
    1,733
    JuHui
    Mar 18, 2006
  5. Iñaki Baz Castillo
    Replies:
    7
    Views:
    807
    Iñaki Baz Castillo
    Jan 12, 2010
Loading...

Share This Page