Have you called the setReuseAddress() with true as a parameter when you created and initialized the service ?
Le 1/27/14 11:29 PM, de...@user1.net a écrit : > My apologies. The server uses multiple SocketAcceptors (another one being > on port 10110) and I mixed them up when sending them to you. > > Here is the info again for 10100 and binding to a single local address... > > After bind: > > tcp6 0 0 118-173.111.65.se:10100 *:* LISTEN > > After client connection: > > tcp6 0 0 118-173.111.65.se:10100 *:* LISTEN > tcp6 0 0 118-173.111.65.se:10100 CPEc8d3a35c2eb4-C:51964 > ESTABLISHED > > After shutdown: > > tcp6 0 0 118-173.111.65.se:10100 CPEc8d3a35c2eb4-C:51964 > TIME_WAIT > > Again sorry for the confusion, > > Derek > > > > On Mon, Jan 27, 2014 at 5:12 PM, Jeff MAURY <jeffma...@jeffmaury.com> wrote: > >> Do you have an idea where the connection from localhost:4422 come from as >> it was not listed when the JVM was running ? >> >> Jeff >> >> >> On Mon, Jan 27, 2014 at 11:05 PM, de...@user1.net <de...@user1.net> wrote: >> >>> O/S I'm currently testing on is Debian Linux 4.0 but I've seen this occur >>> on other flavours of Linux as well but off-hand can't say if it's 100%. >>> >>> In my tests the SocketAcceptor is binding to 10100 on all local >> addresses. >>> After bind: >>> >>> tcp6 0 0 *:10110 *:* >> LISTEN >>> After the client connects: >>> >>> tcp6 0 0 *:10110 *:* >> LISTEN >>> tcp6 0 0 118-173.111.65.se:10100 CPEc8d3a35c2eb4-C:51693 >>> ESTABLISHED >>> >>> After shutdown: >>> >>> tcp6 0 0 localhost:10110 localhost:4422 >>> TIME_WAIT >>> tcp6 0 0 118-173.111.65.se:10100 CPEc8d3a35c2eb4-C:51693 >>> TIME_WAIT >>> >>> Thanks, >>> >>> Derek >>> >>> >>> On Mon, Jan 27, 2014 at 4:32 PM, Jeff MAURY <jeffma...@jeffmaury.com> >>> wrote: >>> >>>> On which platform your server (acceptor) is running. >>>> Can you check the output of netstat after your server JVM has been shut >>>> down ? >>>> >>>> Jeff >>>> >>>> >>>> On Mon, Jan 27, 2014 at 10:29 PM, de...@user1.net <de...@user1.net> >>> wrote: >>>>> Hello, >>>>> >>>>> I realize the original should be in the users mailing list but >> replying >>>>> here to keep the thread intact. >>>>> >>>>> I have been observing the same issue: >>>>> >>>>> - bind() a SocketAcceptor to an address >>>>> - connect a client to the SocketAcceptor >>>>> - while the client is connected call dispose() and then unbind() (and >>>> tried >>>>> also with unbind(true)) on the SocketAcceptor >>>>> - here the vm is terminated and the program restarted >>>>> - attempting to bind() to the same address results in a >>>>> "java.net.BindException: Address already in use" 100% of the time. >>>>> >>>>> I have even tried dispose() then iterating over ever managed session >>> and >>>>> calling IoSession.close() and then unbind(). Same result. >>>>> >>>>> Regards, >>>>> >>>>> Derek >>>>> >>>>> >>>>> >>>>> On Mon, Jan 27, 2014 at 4:44 AM, Emmanuel Lécharny < >>> elecha...@gmail.com >>>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> FTR, dev list is not the right place for such mail. Please use the >>>> users >>>>>> mailing list. >>>>>> >>>>>> Have you disposed the acceptor before unbinding it ? If there is >> any >>>>>> pending connection, it's likely that the socket will be persisted >>> even >>>>>> after an Unbind, for the socket timeout (which might be quite >> long). >>>>>> Always close correctly all the sessions programmatically before >>>>>> unbinding. Dispose do that. >>>>>> >>>>>> >>>>>> Le 1/27/14 10:23 AM, Hardik Kubavat a écrit : >>>>>>> Hi, >>>>>>> >>>>>>> I am unbind the port from IoAcceptor using >>>>>>> >>>>>>> ==> acceptor.unbind(new InetSocketAddress(portNo)); >>>>>>> >>>>>>> So when we try to bind this same port on acceptor it's throws >>>>>>> Exception with Following message >>>>>>> Address already in use. >>>>>>> >>>>>>> As per my requirement I need to bind and unbind port dynamically. >>> And >>>>>>> It is possible that same port we need to unbind and than bind >>> again. >>>>>> >>>>>> -- >>>>>> Regards, >>>>>> Cordialement, >>>>>> Emmanuel Lécharny >>>>>> www.iktek.com >>>>>> >>>>>> >>>> >>>> >>>> -- >>>> Jeff MAURY >>>> >>>> >>>> "Legacy code" often differs from its suggested alternative by actually >>>> working and scaling. >>>> - Bjarne Stroustrup >>>> >>>> http://www.jeffmaury.com >>>> http://riadiscuss.jeffmaury.com >>>> http://www.twitter.com/jeffmaury >>>> >> >> >> -- >> Jeff MAURY >> >> >> "Legacy code" often differs from its suggested alternative by actually >> working and scaling. >> - Bjarne Stroustrup >> >> http://www.jeffmaury.com >> http://riadiscuss.jeffmaury.com >> http://www.twitter.com/jeffmaury >> -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
