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