Robert Stacy | 24 Mar 15:33 2008

Exception: Timer Already Cancelled

Hi Everyone,

I am currently writing software that polls devices on a network using 
SNMP.  I am sending the OID in batches of 5 at a time to the device.  I 
wait 1 second, and if I have not received all of the replies in that 
time I resend the OID that I am missing.  Currently while running the 
program  I get the following exception quite often:

normal exception: Timer already cancelled.
java.lang.IllegalStateException: Timer already cancelled.normal 
exception: Timer already cancelled.
        at java.util.Timer.sched(Unknown Source)
        at java.util.Timer.schedule(Unknown Source)
        at org.snmp4j.Snmp$PendingRequest.pduHandleAssigned(Unknown Source)
        at org.snmp4j.MessageDispatcherImpl.sendPdu(Unknown Source)
        at org.snmp4j.Snmp.sendMessage(Unknown Source)

        at org.snmp4j.Snmp.send(Unknown Source)
        at org.snmp4j.Snmp.send(Unknown Source)

Is this because I have already received the response for the request?  
Why would I get this exception?

Thanks,
Rob
Robert Stacy | 24 Mar 17:42 2008

Re: Exception: Timer Already Cancelled

Robert Stacy wrote:
> Hi Everyone,
>
> I am currently writing software that polls devices on a network using 
> SNMP.  I am sending the OID in batches of 5 at a time to the device.  
> I wait 1 second, and if I have not received all of the replies in that 
> time I resend the OID that I am missing.  Currently while running the 
> program  I get the following exception quite often:
>
> normal exception: Timer already cancelled.
> java.lang.IllegalStateException: Timer already cancelled.normal 
> exception: Timer already cancelled.
>        at java.util.Timer.sched(Unknown Source)
>        at java.util.Timer.schedule(Unknown Source)
>        at org.snmp4j.Snmp$PendingRequest.pduHandleAssigned(Unknown 
> Source)
>        at org.snmp4j.MessageDispatcherImpl.sendPdu(Unknown Source)
>        at org.snmp4j.Snmp.sendMessage(Unknown Source)
>
>        at org.snmp4j.Snmp.send(Unknown Source)
>        at org.snmp4j.Snmp.send(Unknown Source)
>
> Is this because I have already received the response for the request?  
> Why would I get this exception?
>
>
> Thanks,
> Rob
> _______________________________________________
> SNMP4J mailing list
(Continue reading)

Frank Fock | 24 Mar 18:08 2008

Re: Exception: Timer Already Cancelled

Hi Robert,

what SNMP4J version are you using?
When do you call Snmp.cancel(..)?
Why are you not using the built-in resend mechanism
of SNMP4J (by incrementing the retry count)?
Are you creating a new PDU instance for each request?
Is the request ID different for each request?

Best regards,
Frank

Robert Stacy wrote:
> Robert Stacy wrote:
>> Hi Everyone,
>>
>> I am currently writing software that polls devices on a network using 
>> SNMP.  I am sending the OID in batches of 5 at a time to the device.  
>> I wait 1 second, and if I have not received all of the replies in that 
>> time I resend the OID that I am missing.  Currently while running the 
>> program  I get the following exception quite often:
>>
>> normal exception: Timer already cancelled.
>> java.lang.IllegalStateException: Timer already cancelled.normal 
>> exception: Timer already cancelled.
>>        at java.util.Timer.sched(Unknown Source)
>>        at java.util.Timer.schedule(Unknown Source)
>>        at org.snmp4j.Snmp$PendingRequest.pduHandleAssigned(Unknown 
>> Source)
>>        at org.snmp4j.MessageDispatcherImpl.sendPdu(Unknown Source)
(Continue reading)

Christof Meerwald | 24 Mar 22:46 2008

SNMP broadcasts, PDUv1 with Counter64 (in 1.9.1)

Hi,

it appears that with 1.9.1 SNMP broadcasts don't work any more - to be
more precise, you now only get the first response (with code that
worked perfectly fine with previous snmp4j versions). I think this is
related to the following "fix" in 1.9.1:

"Fixed: With async request processing and retry>0 there could have been
a race condition where a response event had been generated twice for a
request."

which appears to now only allow a single response event for each
request (even if the request is not cancelled in the listener as
mentioned in the JavaDoc: "Not canceling a request immediately can be
useful when sending a request to a broadcast address.")

I also noticed that 1.9.1 now contains a factory interface for creating
the PDU class for incoming messages. While this allows one to provide a
PDUv1 class that doesn't throw an exception when encountering a
Counter64 value, it's still a bit of a hassle as it requires quite a
bit of code duplication. I think, snmp4j could quite easily simplify
that particular case further by moving the Counter64 check into a
separate method. That way, a derived "PDUv1WithCounter64" could easily
overwrite that method without having to duplicate any of the decodeBER
code. So my proposal would be to add a new protected method to PDUv1:

protected void checkVariableBindingSyntax(VariableBinding vb)
  throws IOException
{
  if (vb.getSyntax() == SMIConstants.SYNTAX_COUNTER64) {
(Continue reading)

PHIL BERGSTRESSER | 24 Mar 22:52 2008

RE: SNMP broadcasts, PDUv1 with Counter64 (in 1.9.1)

SNMP4J allows Counter64 in SNMPv1 PDUs?
Phil

> -----Original Message-----
> From: snmp4j-bounces@... 
> [mailto:snmp4j-bounces@...] On Behalf Of Christof Meerwald
> Sent: Monday, March 24, 2008 4:46 PM
> To: snmp4j@...
> Subject: [SNMP4J] SNMP broadcasts, PDUv1 with Counter64 (in 1.9.1)
> 
> Hi,
> 
> it appears that with 1.9.1 SNMP broadcasts don't work any 
> more - to be more precise, you now only get the first 
> response (with code that worked perfectly fine with previous 
> snmp4j versions). I think this is related to the following 
> "fix" in 1.9.1:
> 
> "Fixed: With async request processing and retry>0 there could 
> have been a race condition where a response event had been 
> generated twice for a request."
> 
> which appears to now only allow a single response event for 
> each request (even if the request is not cancelled in the 
> listener as mentioned in the JavaDoc: "Not canceling a 
> request immediately can be useful when sending a request to a 
> broadcast address.")
> 
> 
> I also noticed that 1.9.1 now contains a factory interface 
(Continue reading)

Frank Fock | 24 Mar 23:13 2008

Re: SNMP broadcasts, PDUv1 with Counter64 (in 1.9.1)

Hi Christof,

Sorry, this seems to be indeed a regression.
Please try the fix below to fix broadcast
async request processing:

Index: Snmp.java
===================================================================
--- Snmp.java	(revision 402)
+++ Snmp.java	(working copy)
 <at>  <at>  -1117,17 +1117,7  <at>  <at> 
        synchronized (pendingRequests) {
          request = (PendingRequest) pendingRequests.get(handle);
          if (request != null) {
-          if (request.isResponseReceived()) {
-            pendingRequests.remove(handle);
-            request = null;
-            if (logger.isInfoEnabled()) {
-              logger.info("Received second response for request with 
handle "+
-                          handle);
-            }
-          }
-          else {
-            request.responseReceived();
-          }
+          request.responseReceived();
          }
        }
        if (request == null) {
(Continue reading)

Frank Fock | 24 Mar 23:17 2008

Re: SNMP broadcasts, PDUv1 with Counter64 (in 1.9.1)


PHIL BERGSTRESSER wrote:
> SNMP4J allows Counter64 in SNMPv1 PDUs?

No, but there are people who would like
to support it despite the fact that it is
not allowed by the protocol specification.
They can do it with SNMP4J by using their
own PDU class and factory (since v1.9.1).

Frank
Jamie Bisotti | 25 Mar 07:36 2008
Picon

Misleading timeout/retries info when logging Target but using a custom TimeoutModel that does not use Target's timeout/retries

Just passing this along so others don't waste as much time tracking it down
as I did...

We're using a custom TimeoutModel, that allows for variable length retries (
e.g. 500, 1000, 2500, 6000).  An instance of that gets put into our Snmp
instance.  Then, our CommunityTarget gets created, and it has a default
timeout of 1000.  This is what caused my "problem".  The CommunityTarget has
a timeout, but it is not used in my implementation of TimeoutModel.  Maybe
I'm doing something incorrect?  The problem was that when a request
timed-out, I was logging the CommunityTarget, which looked something like
this:

...target=CommunityTarget[address=10.200.1.23/161, version=0, timeout=1000,
retries=0, community=public]...

The 'timeout' of 1000 and the 'retries' of 0 threw me for a loop; I couldn't
figure out where they were coming from.  'retries' should have been 3 and
'timeout' should have depended on which retry it was.

After looking through the snmp4j source a couple of times it finally dawned
on my what was going on.

--

-- 
Jamie Bisotti
Christof Meerwald | 25 Mar 10:02 2008

Re: SNMP broadcasts, PDUv1 with Counter64 (in 1.9.1)

Hi Frank,

thanks, the fix appears to work.

Christof

Frank Fock wrote:
> Hi Christof,
> 
> Sorry, this seems to be indeed a regression.
> Please try the fix below to fix broadcast
> async request processing:
> 
> Index: Snmp.java
> ===================================================================
> --- Snmp.java    (revision 402)
> +++ Snmp.java    (working copy)
>  <at>  <at>  -1117,17 +1117,7  <at>  <at> 
>        synchronized (pendingRequests) {
>          request = (PendingRequest) pendingRequests.get(handle);
>          if (request != null) {
> -          if (request.isResponseReceived()) {
> -            pendingRequests.remove(handle);
> -            request = null;
> -            if (logger.isInfoEnabled()) {
> -              logger.info("Received second response for request with 
> handle "+
> -                          handle);
> -            }
> -          }
(Continue reading)

lalit patel | 25 Mar 13:53 2008
Picon

Asynchronous Request Not Working with SNMP v3

Hi
I wonder why the following code is not working?
........
.......
try{
        TransportMapping transport = new DefaultUdpTransportMapping();
        Snmp snmp= new Snmp(transport);
        USM usm = new USM(SecurityProtocols.getInstance(),
                     new OctetString(MPv3.createLocalEngineID()), 0);
        SecurityModels.getInstance().addSecurityModel(usm);
        //transport.listen();
        // add user to the USM
       snmp.getUSM().addUser(new OctetString(AdminName),
                         new UsmUser(new OctetString(AdminName),
                                     AuthMD5.ID,
                                     new OctetString(Password),
                                     PrivDES.ID,
                                     new OctetString(Password)));
            // create the target
                  UserTarget target[] = new UserTarget[NoOfSite];
                  for(int i=0;i<NoOfSite;i++)
                  {

                     target[i] = new UserTarget();

                     }
           for(int i=0;i<NoOfSite;i++)
                {
                   target[i].setAddress(targetAddress[i]);
                   target[i].setRetries(2);
(Continue reading)


Gmane