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 <[email protected]> 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 >> [email protected] >> 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 > [email protected] > https://oosnmp.net/mailman/listinfo/snmp4j _______________________________________________ SNMP4J mailing list [email protected] https://oosnmp.net/mailman/listinfo/snmp4j
