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

[Frank Fock]

Hi Thomas,

You can access the code from the snapshots repository at:
https://oosnmp.net/dist/snapshot/

The Maven Central sync is planned, although the security 
(authentication) of the process is not finally
proven to be sufficient (from my point of view), but we will see...

Best regards,
Frank

Am 28.05.2015 um 20:25 schrieb Thomas L:
> Hi!
>
> I tested my solution (calling join() by reflection after Snmp.close()) 
> and tested it the whole day with an infinite loop where I start 
> listening for snmp traps, receive snmp traps during a random number of 
> milliseconds (between 0 and 3s) and then do Snmp.close() + join().
> I first ran it for a few minutes before it hung on a deadlock... 
> because of a bug in my code :-) I fixed my bug then ran the test case 
> again for hours without any problem.
>
> Is the code repository of snmp4j publicily available? I would be 
> interested to check the patch you made for that problem.
>
> By the way, it would be great if you would publish snmp4j on Maven 
> Central, because some companies like mine restrict the repositories we 
> can access on the Internet, so I use the snmp4j bundle from Apache 
> servicemix.
>
> Regards,
> Thomas
>
> Le 28 mai 2015 à 01:12, Frank Fock <fock at agentpp.com 
> <mailto:fock at agentpp.com>> a écrit :
>
>> 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 i
>>> s 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?>>> >>> Reg
>>> ards,>>> 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  <https://oosnmp.net/mailman/listinfo/s%0Anmp4j>
>>

-- 
---
AGENT++
Maximilian-Kolbe-Str. 10
73257 Koengen, Germany
https://agentpp.com
Phone: +49 7024 8688230
Fax:   +49 7024 8688231