[SNMP4J] BindException: Address already in use, even with reuseAddress=true (with proposed fix)

[Frank Fock]

Hi Thomas,

Your conclusion below is not true. If the socket timeout is 0 and now 
requst comes in, the worker thread will not loop
and thus not recognize that it should end. The only way to signal the 
termination request is sending an interrupt.
But that is only recognized within an IO wait. If the listener thread is 
after the loop condition but before the IO wait,
it will wait forever (until either a request or an IO exception happens).

I have changed the code to do the join after the socket close (which 
seems to be working - but needs further testing)
in the latest SNMP4J snapshot.

Best regards,
Frank

Am 27.05.2015 um 09:23 schrieb zlika_ese at hotmail.com:
>
> Hello Frank,
>
> If the join causes a deadlock, that means that the thread would never 
> end even if there were not the join, which is not good anyway. So if 
> this deadlock exists, the problem is maybe located in the code of the 
> worker thread.
>
> Thomas
>
>
> ------ Message d'origine------
>
> *De: *Frank Fock
>
> *Date: *mer., 27 mai 2015 09:08
>
> *À: *Thomas L;
>
> *Cc: *snmp4j at agentpp.org <mailto:snmp4j at agentpp.org>;
>
> *Objet :*Re: [SNMP4J] BindException: Address already in use, even with 
> reuseAddress=true (with proposed fix)
>
>
> Hello Thomas,I will try find a solution. However, other users reported the deadlock occurring on some operating systems when the join was made. The problem is, that you cannot be sure that the worker thread is already at the io wait. But you are right, the socket close should anyway terminate the thread...Best regards Frank> Am27.05.2015  <tel:27.05.2015>  um 07:31 schrieb Thomas L:> > Hello Frank,> > Thank you for your answer.> Setting a socket timeout is not something I would like to do, because you have the choice between using a small value and wasting CPU time, or setting a large value and waiting a long time for the close method to complete. I do not want either.> My solution seems completly safe: just do a join at the end ofDefaultUdpTransportMapping.cl  <http://DefaultUdpTransportMapping.cl>ose(), after the socket has been closed. The worker thread is then already terminating, I just want the close method to wait a few ms just to be sure that when we exit the close method it is safe to immediatly try to rebind on the same port. I do not see any possible deadlock here.> > Regards,> Thomas> >> Le 27 mai 2015 à 00:07, Frank Fock  a écrit :>> >> Hi Thomas,>> >> If you set the socket timeout to a value >0 (which is recommended), then>> the worker thread is joined on the close().>> If the timeout is 0, no join is performed because otherwise a deadlock would occur>> if the interrupt call is triggered by the close() method while the worker thread>> is not in the select method (i.e., waiting on IO).>> >> Thus, I would not change the existing code.>> >> Best regards,>> Frank>> >>> Am26.05.2015  <tel:26.05.2015>  um 22:13 schrieb Thomas L:>>> Hello,>>> >>> I think I have found a bug in SNMP4J (2.3.3) where we can have a "BindException: Address already in use" exception when creating a DefaultUdpTransportMapping, whereas reuseAddress=true, if we have previously created and closed a similar DefaultUdpTransportMapping.>>> InDefaultUdpTransportMapping.cl  <http://DefaultUdpTransportMapping.cl>ose(), the listener thread (WorkerTask) is not "joined", so it can still use the UDP port for some time, and creating a new DefaultUdpTransportMapping on the same port, even if reuseAddress=true, is not possible.>>> My current dirty workaround is to access the "WorkerTask" field by reflection just before closing the Snmp object, and then calling "join()" on the object, so I am sure the thread is correctly terminated before any new attempt to create a new DefaultUdpTransportMapping.>>> >>> Can this problem be solved in the next version of SNM4J?>>> >>> Regards,>>> Thomas>>> _______________________________________________>>> SNMP4J mailing list>>>  SNMP4J at agentpp.org  <mailto:%20SNMP4J at agentpp.org>>>>https://oosnmp.net/mailman/listinfo/snmp4j>> >> -- >> --->> AGENT++>> Maximilian-Kolbe-Str. 10>> 73257 Koengen, Germany>>https://agentpp.com>> Phone:+49 7024 8688230  <tel:+49%207024%208688230>>> Fax:+49 7024 8688231  <tel:+49%207024%208688231>>> >> _______________________________________________>> SNMP4J mailing list>>  SNMP4J at agentpp.org  <mailto:%20SNMP4J at agentpp.org>>>https://oosnmp.net/mailman/listinfo/snmp4j