Apache AWF
  1. Apache AWF
  2. AWF-9

setReuseAddress(true) in HttpServer

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Labels:
      None

      Description

      If I terminate deft from eclipse and then start it up again I get an "Address already in use" because the socket is in the TIME_WAIT stage. The solution for this is so set SO_REUSEADDR on the socket which corresponds to ServerSocket.setReuseAddress(true) in java.

        Activity

        Hide
        Johnathan Meehan added a comment -

        Ready for review.

        Show
        Johnathan Meehan added a comment - Ready for review.
        Hide
        Johnathan Meehan added a comment - - edited

        Set this value; also logged where changed from system default, as call outside of time-critical block.

        Committed: http://svn.apache.org/viewvc?rev=1154365&view=rev

        Show
        Johnathan Meehan added a comment - - edited Set this value; also logged where changed from system default, as call outside of time-critical block. Committed: http://svn.apache.org/viewvc?rev=1154365&view=rev
        Hide
        Adam Lofts added a comment -

        BTW - this has some interesting points: http://hea-www.harvard.edu/~fine/Tech/addrinuse.html

        Show
        Adam Lofts added a comment - BTW - this has some interesting points: http://hea-www.harvard.edu/~fine/Tech/addrinuse.html
        Hide
        Roger Schildmeijer added a comment -

        I think I agree. Set SO_REUSEADDR true is probably a good idea.

        You will still receive an IOException during bind if the (previous) socket is in another state...

        Show
        Roger Schildmeijer added a comment - I think I agree. Set SO_REUSEADDR true is probably a good idea. You will still receive an IOException during bind if the (previous) socket is in another state...
        Hide
        Adam Lofts added a comment -

        I fail to see the disadvantage of ensuring SO_REUSEADDR is true. All the references I've read suggest it for server sockets. You reference warns that "It may confuse the server" however this should not be a problem since the http header parsing will simply fail and the socket closed.

        That said - the default does appear to be true on my machine so I'm now not clear exactly what is going on.

        Show
        Adam Lofts added a comment - I fail to see the disadvantage of ensuring SO_REUSEADDR is true. All the references I've read suggest it for server sockets. You reference warns that "It may confuse the server" however this should not be a problem since the http header parsing will simply fail and the socket closed. That said - the default does appear to be true on my machine so I'm now not clear exactly what is going on.
        Hide
        Roger Schildmeijer added a comment -
        Show
        Roger Schildmeijer added a comment - more about this subject: http://www.unixguide.net/network/socketfaq/4.5.shtml
        Hide
        Roger Schildmeijer added a comment -

        Please check the default value on your machine.

        There is a reason to have SO_REUSEADDR false. For TCP, when a connection is closed, one (or both) endpoints must hang around for a while in "Time-Wait" state to vacuum up stray packets. The "quiet time" is supposed to be equal to twice the maximum amount of time a packet can remain in the network. In practice, the length of the quiet time is implementation dependent, because there is no real mechanism that limits how long a packet can be delayed by the network. Values in use range from 4minutes down to 30 seconds or even short.

        Show
        Roger Schildmeijer added a comment - Please check the default value on your machine. There is a reason to have SO_REUSEADDR false. For TCP, when a connection is closed, one (or both) endpoints must hang around for a while in "Time-Wait" state to vacuum up stray packets. The "quiet time" is supposed to be equal to twice the maximum amount of time a packet can remain in the network. In practice, the length of the quiet time is implementation dependent, because there is no real mechanism that limits how long a packet can be delayed by the network. Values in use range from 4minutes down to 30 seconds or even short.
        Hide
        Adam Lofts added a comment -

        I haven't actually tried setting this. I did check that the socket was in TIME_WAIT which closely match the docs for SO_REUSEADDR. I'm on Ubuntu with OpenJDK.

        I can check this is the right solution. Given that the java docs say the default is platform dependent it seems prudent to call this anyway.

        Show
        Adam Lofts added a comment - I haven't actually tried setting this. I did check that the socket was in TIME_WAIT which closely match the docs for SO_REUSEADDR. I'm on Ubuntu with OpenJDK. I can check this is the right solution. Given that the java docs say the default is platform dependent it seems prudent to call this anyway.
        Hide
        Michele Zuccalà added a comment -

        I never noticed this problem, I get the same result of Roger on my machine (GNU/Linux Slackware 13.37)

        Show
        Michele Zuccalà added a comment - I never noticed this problem, I get the same result of Roger on my machine (GNU/Linux Slackware 13.37)
        Hide
        Roger Schildmeijer added a comment -

        Interesting. Have you tried to explicitly enable SO_REUSEADDR? Did it solve your problem?

        I tried locally on my machine (OS X 10.7), and the default value for this was 'true'.
        added
        System.out.println(serverChannel.socket().getReuseAddress()); (in org.deftserver.web.HttpServer)

        The documentation about ServerSocketChannel.setReuseAddress says:
        "When a ServerSocket is created the initial setting of SO_REUSEADDR is not defined. Applications can use getReuseAddress() to determine the initial setting of SO_REUSEADDR"

        Show
        Roger Schildmeijer added a comment - Interesting. Have you tried to explicitly enable SO_REUSEADDR? Did it solve your problem? I tried locally on my machine (OS X 10.7), and the default value for this was 'true'. added System.out.println(serverChannel.socket().getReuseAddress()); (in org.deftserver.web.HttpServer) The documentation about ServerSocketChannel.setReuseAddress says: "When a ServerSocket is created the initial setting of SO_REUSEADDR is not defined. Applications can use getReuseAddress() to determine the initial setting of SO_REUSEADDR"

          People

          • Assignee:
            Johnathan Meehan
            Reporter:
            Adam Lofts
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development