[SNMP4J] SNMP broadcasts, PDUv1 with Counter64 (in 1.9.1)
Frank Fock
fock at agentpp.com
Mon Mar 24 23:13:12 CET 2008
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)
@@ -1117,17 +1117,7 @@
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) {
I will consider isolating the Counter64 check into
a protected method.
Best regards,
Frank
Christof Meerwald wrote:
> 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) {
> throw new MessageException("Counter64 encountered in SNMPv1 PDU
> "+
> "(RFC 2576 ยง4.1.2.1)");
> }
> }
>
> and call checkVariableBindingSyntax(vb) in decodeBER (line 169).
>
> Any thoughts on this?
>
>
> Christof
>
--
AGENT++
http://www.agentpp.com
http://www.mibexplorer.com
http://www.mibdesigner.com
More information about the SNMP4J
mailing list