Unsubscribe Sent from my iPhone
On 2010-09-27, at 7:00 AM, [email protected] wrote: > Send SNMP4J mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.agentpp.org/mailman/listinfo/snmp4j > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of SNMP4J digest..." > > > Today's Topics: > > 1. Remove row in table using the oid (Paulo Abreu) > 2. SNMPv3 response is null when switch is rebooted (Wadood Ahmed) > 3. Re: SNMPv3 response is null when switch is rebooted (Frank Fock) > 4. Re: Another race condition fix forDefaultUdpTransportMapping > (Tosoni) > 5. Re: Another race condition fix forDefaultUdpTransportMapping > (Paul Marquis) > 6. Re: Another race condition fix forDefaultUdpTransportMapping > (Tosoni) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 26 Sep 2010 14:47:40 +0100 > From: "Paulo Abreu" <[email protected]> > Subject: [SNMP4J] Remove row in table using the oid > To: <[email protected]> > Message-ID: > > <!&!AAAAAAAAAAAYAAAAAAAAABdAwzuUoBNPrDNqPO2OCTwCgQAAEAAAAE/[email protected]> > > Content-Type: text/plain; charset="us-ascii" > > Can you help me using an example of how to remove a row from a table using > the oid of this line? > > > > Thanks > > Paulo > > > > > > ------------------------------ > > Message: 2 > Date: Sun, 26 Sep 2010 18:25:07 +0000 (UTC) > From: Wadood Ahmed <[email protected]> > Subject: [SNMP4J] SNMPv3 response is null when switch is rebooted > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > Hello All, > > I am newbie in SNMP domain. I have an issue with SNMPv3 > > I have SNMPv3 user and it works perfectly (read/write). But when i reboot the > switch - I get null response in snmp4j code. When I do a wireshark it shows > messages being sent/received - REPORT messages are being sent by the switch > with > different authorization engine time and boot time. > > Why does snmp4j not throw a REPORT error instead of response being null? Is > this > a bug in snmp4j? If so, in which version is this fixed. > > thanks > Wadood > > > > ------------------------------ > > Message: 3 > Date: Sun, 26 Sep 2010 20:32:26 +0200 > From: Frank Fock <[email protected]> > Subject: Re: [SNMP4J] SNMPv3 response is null when switch is rebooted > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi, > > Most likely, it is a bug in the switch. It does not increase > its boot counter when it is rebooted. SNMP4J behaves > as required by the USM standard. > > Best regards, > Frank > > On 26.09.2010 20:25, Wadood Ahmed wrote: >> Hello All, >> >> I am newbie in SNMP domain. I have an issue with SNMPv3 >> >> I have SNMPv3 user and it works perfectly (read/write). But when i reboot the >> switch - I get null response in snmp4j code. When I do a wireshark it shows >> messages being sent/received - REPORT messages are being sent by the switch >> with >> different authorization engine time and boot time. >> >> Why does snmp4j not throw a REPORT error instead of response being null? Is >> this >> a bug in snmp4j? If so, in which version is this fixed. >> >> thanks >> Wadood >> >> _______________________________________________ >> SNMP4J mailing list >> [email protected] >> http://lists.agentpp.org/mailman/listinfo/snmp4j > > -- > AGENT++ > http://www.agentpp.com > http://www.snmp4j.com > http://www.mibexplorer.com > http://www.mibdesigner.com > > > > ------------------------------ > > Message: 4 > Date: Mon, 27 Sep 2010 09:38:18 +0200 > From: "Tosoni" <[email protected]> > Subject: Re: [SNMP4J] Another race condition fix > forDefaultUdpTransportMapping > To: "'Paul Marquis'" <[email protected]>, "'Frank Fock'" > <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Sorry guys, but I don't believe your tries fix the race for real. > > The problem is that a socket.close() can occur just before the > socket.receive() > If you just test the socket value, this does not forbit a socket.close() > happening *after* > your test and *before* the socket.receive().> > try { >>> DatagramSocket socketCopy = socket; >>> if (socketCopy == null) { >>> stop = true; >>> continue; >>> } > *** what if another thread closes at this point ? *** >>> socketCopy.receive(packet); >>> } > > The real fix must use some semaphore or mutex which embraces: > on one hand, both the test of 'socket==null' and the receive() > on the other hand, both the change 'socket=null' and the close() > > My own try (I do not suggest it as a correct fix) is a quick-and-dirty: > try { > socket.receive(packet); > } > catch (InterruptedIOException iiox) { > if (iiox.bytesTransferred <= 0) { > continue; > } > } > + // UGLY FIX: socket close/receive synchro > + catch (NullPointerException iiox) { > + // This handles the close race (stop=false but socket=null) > + continue; > + } > > > Hmm, also, there is another race condition which happens sometimes, here: > public void run() { > try { > here===> socket.setSoTimeout(getSocketTimeout()); > Really I guess it can happen everywhere 'socket' is used in a thread > different than the closing thread... > > Regards > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]]on >> Behalf Of Paul Marquis >> Sent: Friday, September 24, 2010 1:32 AM >> To: Frank Fock >> Cc: [email protected] >> Subject: Re: [SNMP4J] Another race condition fix >> forDefaultUdpTransportMapping >> >> >> Thanks for fixing this! >> >> Any idea when there will be an official release with this fix >> in it? >> I just joined the list, so if you've already discussed when the next >> release will be available, I apologize. >> >> On Sep 23, 2010, at 7:24 PM, Frank Fock wrote: >> >>> Hi Paul, >>> >>> Thank you for the bug report. If fixed it a bit different: >>> >>> try { >>> DatagramSocket socketCopy = socket; >>> if (socketCopy == null) { >>> stop = true; >>> continue; >>> } >>> socketCopy.receive(packet); >>> } >>> >>> Best regards, >>> Frank >>> >>> On 23.09.2010 23:44, Paul Marquis wrote: >>>> Version 1.11.1 of SNMP4J included a fix for a race condition in >>>> DefautlUdpTrasnportMapping which caused a NullPointerException. >>>> However, there is still one that remains while attempting to read a >>>> packet and I see this from time to time. Below is a patch >> that fixes >>>> the problem for me that I'd like to submit for review. >>>> >>>> Index: src/org/snmp4j/transport/DefaultUdpTransportMapping.java >>>> =================================================================== >>>> --- >> src/org/snmp4j/transport/DefaultUdpTransportMapping.java >>>> (revision >>>> 215) >>>> +++ >> src/org/snmp4j/transport/DefaultUdpTransportMapping.java (working >>>> copy) >>>> @@ -337,7 +337,11 @@ >>>> >>>> udpAddress.getPort()); >>>> try { >>>> try { >>>> - socket.receive(packet); >>>> + DatagramSocket readingSocket = socket; >>>> + if (readingSocket == null) { >>>> + continue; >>>> + } >>>> + readingSocket.receive(packet); >>>> } >>>> catch (InterruptedIOException iiox) { >>>> if (iiox.bytesTransferred<= 0) { >>>> >>>> _______________________________________________ >>>> SNMP4J mailing list >>>> [email protected] >>>> http://lists.agentpp.org/mailman/listinfo/snmp4j >>> >>> -- >>> AGENT++ >>> http://www.agentpp.com >>> http://www.snmp4j.com >>> http://www.mibexplorer.com >>> http://www.mibdesigner.com >>> >>> _______________________________________________ >>> SNMP4J mailing list >>> [email protected] >>> http://lists.agentpp.org/mailman/listinfo/snmp4j >> >> _______________________________________________ >> SNMP4J mailing list >> [email protected] >> http://lists.agentpp.org/mailman/listinfo/snmp4j >> > > > > ------------------------------ > > Message: 5 > Date: Mon, 27 Sep 2010 05:20:45 -0400 > From: Paul Marquis <[email protected]> > Subject: Re: [SNMP4J] Another race condition fix > forDefaultUdpTransportMapping > To: "Tosoni" <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > If another thread closes where you say, you should get an IOException > or SocketException, not a NullPointerException, when receive() is > called. The socket member variable may change to null, but socketCopy > will not. > > On Sep 27, 2010, at 3:38 AM, Tosoni wrote: > >> Sorry guys, but I don't believe your tries fix the race for real. >> >> The problem is that a socket.close() can occur just before the >> socket.receive() >> If you just test the socket value, this does not forbit a >> socket.close() >> happening *after* >> your test and *before* the socket.receive().> > try { >>>> DatagramSocket socketCopy = socket; >>>> if (socketCopy == null) { >>>> stop = true; >>>> continue; >>>> } >> *** what if another thread closes at this point ? *** >>>> socketCopy.receive(packet); >>>> } >> >> The real fix must use some semaphore or mutex which embraces: >> on one hand, both the test of 'socket==null' and the receive() >> on the other hand, both the change 'socket=null' and the close() >> >> My own try (I do not suggest it as a correct fix) is a quick-and- >> dirty: >> try { >> socket.receive(packet); >> } >> catch (InterruptedIOException iiox) { >> if (iiox.bytesTransferred <= 0) { >> continue; >> } >> } >> + // UGLY FIX: socket close/receive synchro >> + catch (NullPointerException iiox) { >> + // This handles the close race (stop=false but >> socket=null) >> + continue; >> + } >> >> >> Hmm, also, there is another race condition which happens sometimes, >> here: >> public void run() { >> try { >> here===> socket.setSoTimeout(getSocketTimeout()); >> Really I guess it can happen everywhere 'socket' is used in a thread >> different than the closing thread... >> >> Regards >> >>> -----Original Message----- >>> From: [email protected] [mailto:snmp4j- >>> [email protected]]on >>> Behalf Of Paul Marquis >>> Sent: Friday, September 24, 2010 1:32 AM >>> To: Frank Fock >>> Cc: [email protected] >>> Subject: Re: [SNMP4J] Another race condition fix >>> forDefaultUdpTransportMapping >>> >>> >>> Thanks for fixing this! >>> >>> Any idea when there will be an official release with this fix >>> in it? >>> I just joined the list, so if you've already discussed when the next >>> release will be available, I apologize. >>> >>> On Sep 23, 2010, at 7:24 PM, Frank Fock wrote: >>> >>>> Hi Paul, >>>> >>>> Thank you for the bug report. If fixed it a bit different: >>>> >>>> try { >>>> DatagramSocket socketCopy = socket; >>>> if (socketCopy == null) { >>>> stop = true; >>>> continue; >>>> } >>>> socketCopy.receive(packet); >>>> } >>>> >>>> Best regards, >>>> Frank >>>> >>>> On 23.09.2010 23:44, Paul Marquis wrote: >>>>> Version 1.11.1 of SNMP4J included a fix for a race condition in >>>>> DefautlUdpTrasnportMapping which caused a NullPointerException. >>>>> However, there is still one that remains while attempting to read a >>>>> packet and I see this from time to time. Below is a patch >>> that fixes >>>>> the problem for me that I'd like to submit for review. >>>>> >>>>> Index: src/org/snmp4j/transport/DefaultUdpTransportMapping.java >>>>> =================================================================== >>>>> --- >>> src/org/snmp4j/transport/DefaultUdpTransportMapping.java >>>>> (revision >>>>> 215) >>>>> +++ >>> src/org/snmp4j/transport/DefaultUdpTransportMapping.java (working >>>>> copy) >>>>> @@ -337,7 +337,11 @@ >>>>> >>>>> udpAddress.getPort()); >>>>> try { >>>>> try { >>>>> - socket.receive(packet); >>>>> + DatagramSocket readingSocket = socket; >>>>> + if (readingSocket == null) { >>>>> + continue; >>>>> + } >>>>> + readingSocket.receive(packet); >>>>> } >>>>> catch (InterruptedIOException iiox) { >>>>> if (iiox.bytesTransferred<= 0) { >>>>> >>>>> _______________________________________________ >>>>> SNMP4J mailing list >>>>> [email protected] >>>>> http://lists.agentpp.org/mailman/listinfo/snmp4j >>>> >>>> -- >>>> AGENT++ >>>> http://www.agentpp.com >>>> http://www.snmp4j.com >>>> http://www.mibexplorer.com >>>> http://www.mibdesigner.com >>>> >>>> _______________________________________________ >>>> SNMP4J mailing list >>>> [email protected] >>>> http://lists.agentpp.org/mailman/listinfo/snmp4j >>> >>> _______________________________________________ >>> SNMP4J mailing list >>> [email protected] >>> http://lists.agentpp.org/mailman/listinfo/snmp4j >>> >> > > > > ------------------------------ > > Message: 6 > Date: Mon, 27 Sep 2010 11:47:19 +0200 > From: "Tosoni" <[email protected]> > Subject: Re: [SNMP4J] Another race condition fix > forDefaultUdpTransportMapping > To: "'Paul Marquis'" <[email protected]>, "Jean-Pierre TOSONI" > <[email protected]> > Cc: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > Oh yes, you are correct and I am wrong ! I apologize. > But then we should catch IOException or ClosedChannelException ? > And do the same for the other uses of 'socket' in this function ? > >> From: Paul Marquis [mailto:[email protected]] > (snip) >> >> If another thread closes where you say, you should get an >> IOException or SocketException, not a NullPointerException, >> when receive() is called. The socket member variable may >> change to null, but socketCopy will not. >> >> On Sep 27, 2010, at 3:38 AM, Tosoni wrote: >> >>> Sorry guys, but I don't believe your tries fix the race for real. >>> >>> The problem is that a socket.close() can occur just before the >>> socket.receive() >>> If you just test the socket value, this does not forbit a >>> socket.close() >>> happening *after* >>> your test and *before* the socket.receive().> > try { >>>>> DatagramSocket socketCopy = socket; >>>>> if (socketCopy == null) { >>>>> stop = true; >>>>> continue; >>>>> } >>> *** what if another thread closes at this point ? *** >>>>> socketCopy.receive(packet); >>>>> } >>> >>> The real fix must use some semaphore or mutex which embraces: >>> on one hand, both the test of 'socket==null' and the receive() >>> on the other hand, both the change 'socket=null' and the close() >>> >>> My own try (I do not suggest it as a correct fix) is a quick-and- >>> dirty: >>> try { >>> socket.receive(packet); >>> } >>> catch (InterruptedIOException iiox) { >>> if (iiox.bytesTransferred <= 0) { >>> continue; >>> } >>> } >>> + // UGLY FIX: socket close/receive synchro >>> + catch (NullPointerException iiox) { >>> + // This handles the close race (stop=false but >>> socket=null) >>> + continue; >>> + } >>> >>> >>> Hmm, also, there is another race condition which happens >> sometimes, >>> here: >>> public void run() { >>> try { >>> here===> socket.setSoTimeout(getSocketTimeout()); >>> Really I guess it can happen everywhere 'socket' is used in a thread >>> different than the closing thread... >>> >>> Regards >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:snmp4j- >>>> [email protected]]on >>>> Behalf Of Paul Marquis >>>> Sent: Friday, September 24, 2010 1:32 AM >>>> To: Frank Fock >>>> Cc: [email protected] >>>> Subject: Re: [SNMP4J] Another race condition fix >>>> forDefaultUdpTransportMapping >>>> >>>> >>>> Thanks for fixing this! >>>> >>>> Any idea when there will be an official release with this fix >>>> in it? >>>> I just joined the list, so if you've already discussed >> when the next >>>> release will be available, I apologize. >>>> >>>> On Sep 23, 2010, at 7:24 PM, Frank Fock wrote: >>>> >>>>> Hi Paul, >>>>> >>>>> Thank you for the bug report. If fixed it a bit different: >>>>> >>>>> try { >>>>> DatagramSocket socketCopy = socket; >>>>> if (socketCopy == null) { >>>>> stop = true; >>>>> continue; >>>>> } >>>>> socketCopy.receive(packet); >>>>> } >>>>> >>>>> Best regards, >>>>> Frank >>>>> >>>>> On 23.09.2010 23:44, Paul Marquis wrote: >>>>>> Version 1.11.1 of SNMP4J included a fix for a race condition in >>>>>> DefautlUdpTrasnportMapping which caused a NullPointerException. >>>>>> However, there is still one that remains while >> attempting to read a >>>>>> packet and I see this from time to time. Below is a patch >>>> that fixes >>>>>> the problem for me that I'd like to submit for review. >>>>>> >>>>>> Index: src/org/snmp4j/transport/DefaultUdpTransportMapping.java >>>>>> >> =================================================================== >>>>>> --- >>>> src/org/snmp4j/transport/DefaultUdpTransportMapping.java >>>>>> (revision >>>>>> 215) >>>>>> +++ >>>> src/org/snmp4j/transport/DefaultUdpTransportMapping.java (working >>>>>> copy) >>>>>> @@ -337,7 +337,11 @@ >>>>>> >>>>>> udpAddress.getPort()); >>>>>> try { >>>>>> try { >>>>>> - socket.receive(packet); >>>>>> + DatagramSocket readingSocket = socket; >>>>>> + if (readingSocket == null) { >>>>>> + continue; >>>>>> + } >>>>>> + readingSocket.receive(packet); >>>>>> } >>>>>> catch (InterruptedIOException iiox) { >>>>>> if (iiox.bytesTransferred<= 0) { >>>>>> >>>>>> _______________________________________________ >>>>>> SNMP4J mailing list >>>>>> [email protected] >>>>>> http://lists.agentpp.org/mailman/listinfo/snmp4j >>>>> >>>>> -- >>>>> AGENT++ >>>>> http://www.agentpp.com >>>>> http://www.snmp4j.com >>>>> http://www.mibexplorer.com >>>>> http://www.mibdesigner.com >>>>> >>>>> _______________________________________________ >>>>> SNMP4J mailing list >>>>> [email protected] >>>>> http://lists.agentpp.org/mailman/listinfo/snmp4j >>>> >>>> _______________________________________________ >>>> SNMP4J mailing list >>>> [email protected] >>>> http://lists.agentpp.org/mailman/listinfo/snmp4j >>>> >>> >> >> > > > ------------------------------ > > _______________________________________________ > SNMP4J mailing list > [email protected] > http://lists.agentpp.org/mailman/listinfo/snmp4j > > > End of SNMP4J Digest, Vol 80, Issue 15 > ************************************** _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
