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 > Am 27.05.2015 um 07:31 schrieb Thomas L <[email protected]>: > > 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
