Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3
Hi Peter,
How do call the send method? Is the listener set there?
All fields null should not happen normally
Best regards,
Frank
Am 04.10.2016 um 11:18 schrieb Peter Verthez:
Hi Frank,
Our code is simply:
ResponseListener respListener = new
ResponseListener() {
@Override
public void onResponse(ResponseEvent event) {
// canceling is required as per SNMP4J
documentation
((Snmp)event.getSource()).cancel(event.getRequest(), this);
PDU response = event.getResponse();
updateStats(session, agentId, startTime,
response);
listener.onResponse(response,
event.getUserObject());
}
};
session.send(pdu, SnmpUserTarget.this,
userContext, respListener);
It doesn't reach even the first line of the onResponse method.
I've been debugging a little, and the PendingRequest.run() method in
the Snmp class is always being exited because all fields are null, and
so it never calls the onResponse method on the listener. This is
also what the debug message says:
2016-09-28 16:43:36,861 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
PendingRequest canceled key=null, pdu=null, target=null,
transport=null, listener=null
I've then put a breakpoint in the cancel() method, and it gets run
when the following report is coming in (copied from the debugger):
REPORT[{contextEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,
contextName=nt}, requestID=0, errorStatus=0, errorIndex=0,
VBS[1.3.6.1.6.3.15.1.1.3.0 = 18]]
Best regards,
Peter.
On 3/10/2016 23:06, Frank Fock wrote:
Hi Peter,
Yes, the ResponseEvent should be returned after the timeout with a
null response.
From the log, it is unclear why you do not get the event. Is there an
if-statement
that ignores the ResponseEvent with null response in your code?
Best regards,
Frank
Am 30.09.2016 um 10:12 schrieb Peter Verthez:
Hi Frank,
If we are using asynchronous SNMP calls with SNMPv3, what should be
the behaviour in case of timeout, when you used wrong credentials
such as a wrong user name.Should the ResponseListener always be
triggered, with event.getResponse() = null, after the timeout?
I would expect that, but it looks like this is not what I'm seeing:
the ResponseListener does not seem to be triggered in that case. So
this means that our application never knows that a timeout
occurred. We are using currently SNMP4J 2.5.0. Debug logging from
SNMP4J:
2016-09-28 16:43:31,768 DEBUG [JM-49-Ping-Ping-4]-[org.snmp4j.Snmp]
Running pending async request with handle PduHandle[1071987217] and
retry count left 1
2016-09-28 16:43:31,768 DEBUG
[JM-49-Ping-Ping-4]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending
message to 135.249.41.44/161 with length 268:
30:82:01:08:02:01:01:04:06:70:75:62:6c:69:63:a0:81:fa:02:04:3f:e5:3a:11:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
2016-09-28 16:43:35,771 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
Running pending async request with handle PduHandle[1071987217] and
retry count left 0
2016-09-28 16:43:35,771 DEBUG [SNMP4J
Timer]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending
message to 135.249.41.44/161 with length 268:
30:82:01:08:02:01:01:04:06:70:75:62:6c:69:63:a0:81:fa:02:04:3f:e5:3a:11:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
2016-09-28 16:43:36,861 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
PendingRequest canceled key=null, pdu=null, target=null,
transport=null, listener=null
2016-09-28
Re: [SNMP4J] Behaviour of ResponseListener in SNMP V3
Hi Frank,
Our code is simply:
ResponseListener respListener = new
ResponseListener() {
@Override
public void onResponse(ResponseEvent event) {
// canceling is required as per SNMP4J
documentation
((Snmp)event.getSource()).cancel(event.getRequest(), this);
PDU response = event.getResponse();
updateStats(session, agentId, startTime,
response);
listener.onResponse(response,
event.getUserObject());
}
};
session.send(pdu, SnmpUserTarget.this, userContext,
respListener);
It doesn't reach even the first line of the onResponse method.
I've been debugging a little, and the PendingRequest.run() method in the
Snmp class is always being exited because all fields are null, and so it
never calls the onResponse method on the listener. This is also what
the debug message says:
2016-09-28 16:43:36,861 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
PendingRequest canceled key=null, pdu=null, target=null, transport=null,
listener=null
I've then put a breakpoint in the cancel() method, and it gets run when
the following report is coming in (copied from the debugger):
REPORT[{contextEngineID=80:00:02:7d:03:00:90:d0:6d:fa:bc,
contextName=nt}, requestID=0, errorStatus=0, errorIndex=0,
VBS[1.3.6.1.6.3.15.1.1.3.0 = 18]]
Best regards,
Peter.
On 3/10/2016 23:06, Frank Fock wrote:
Hi Peter,
Yes, the ResponseEvent should be returned after the timeout with a
null response.
From the log, it is unclear why you do not get the event. Is there an
if-statement
that ignores the ResponseEvent with null response in your code?
Best regards,
Frank
Am 30.09.2016 um 10:12 schrieb Peter Verthez:
Hi Frank,
If we are using asynchronous SNMP calls with SNMPv3, what should be
the behaviour in case of timeout, when you used wrong credentials
such as a wrong user name.Should the ResponseListener always be
triggered, with event.getResponse() = null, after the timeout?
I would expect that, but it looks like this is not what I'm seeing:
the ResponseListener does not seem to be triggered in that case. So
this means that our application never knows that a timeout
occurred. We are using currently SNMP4J 2.5.0. Debug logging from
SNMP4J:
2016-09-28 16:43:31,768 DEBUG [JM-49-Ping-Ping-4]-[org.snmp4j.Snmp]
Running pending async request with handle PduHandle[1071987217] and
retry count left 1
2016-09-28 16:43:31,768 DEBUG
[JM-49-Ping-Ping-4]-[org.snmp4j.transport.DefaultUdpTransportMapping]
Sending message to 135.249.41.44/161 with length 268:
30:82:01:08:02:01:01:04:06:70:75:62:6c:69:63:a0:81:fa:02:04:3f:e5:3a:11:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
2016-09-28 16:43:35,771 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
Running pending async request with handle PduHandle[1071987217] and
retry count left 0
2016-09-28 16:43:35,771 DEBUG [SNMP4J
Timer]-[org.snmp4j.transport.DefaultUdpTransportMapping] Sending
message to 135.249.41.44/161 with length 268:
30:82:01:08:02:01:01:04:06:70:75:62:6c:69:63:a0:81:fa:02:04:3f:e5:3a:11:02:01:00:02:01:00:30:81:eb:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:06:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:09:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:0b:02:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:23:3c:03:02:00:05:00:30:0c:06:08:2b:06:01:02:01:01:03:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:07:00:05:00:30:0c:06:08:2b:06:01:02:01:01:02:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:17:01:03:00:05:00:30:10:06:0c:2b:06:01:04:01:84:7d:3d:01:09:0d:00:05:00:30:12:06:0e:2b:06:01:04:01:84:7d:3d:01:17:02:01:04:01:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:01:00:05:00:30:11:06:0d:2b:06:01:04:01:84:7d:3d:01:09:1c:02:00:05:00
2016-09-28 16:43:36,861 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
PendingRequest canceled key=null, pdu=null, target=null,
transport=null, listener=null
2016-09-28 16:43:43,771 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
Request timed out: 1071987217
2016-09-28 16:43:43,772 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
Cancelling pending request with handle
