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 FockDate: mer., 27 mai 2015 09:08À:
Thomas L;Cc: [email protected];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> Am 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 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 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
