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

[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 of DefaultUdpTransportMapping.close(), 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 <fock at agentpp.com> 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
> 
>> Am 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.
>> In DefaultUdpTransportMapping.close(), 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
>> https://oosnmp.net/mailman/listinfo/snmp4j
> 
> -- 
> ---
> AGENT++
> Maximilian-Kolbe-Str. 10
> 73257 Koengen, Germany
> https://agentpp.com
> Phone: +49 7024 8688230
> Fax:   +49 7024 8688231
> 
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> https://oosnmp.net/mailman/listinfo/snmp4j