headers
Robert Stacy | 24 Mar 2008 15:33
Favicon

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
Permalink | Reply | 2 comments |
headers
Robert Stacy | 24 Mar 2008 17:42
Favicon

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)

Permalink | Reply | 1 comment |
headers
Frank Fock | 24 Mar 2008 18:08
Favicon

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)

Permalink | Reply | 0 comments |
headers
Christof Meerwald | 24 Mar 2008 22:46
Favicon

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)

Permalink | Reply | 4 comments |
headers
PHIL BERGSTRESSER | 24 Mar 2008 22:52
Favicon

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)

Permalink | Reply | 1 comment |
headers
Frank Fock | 24 Mar 2008 23:13
Favicon

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)

Permalink | Reply | 1 comment |
headers
Frank Fock | 24 Mar 2008 23:17
Favicon

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
Permalink | Reply | 0 comments |
headers
Jamie Bisotti | 25 Mar 2008 07:36
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
Permalink | Reply | 0 comments |
headers
Christof Meerwald | 25 Mar 2008 10:02
Favicon

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)

Permalink | Reply | 0 comments |
headers
lalit patel | 25 Mar 2008 13:53
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)

Permalink | Reply | 0 comments |

Gmane