Hi Frank,
OK, I found the issue. We are providing our own TimerFactory, because
we found that in certain cases the timer of SNMP4J could leak
exceptions, which was causing problems in our application (a timer is
not run anymore when one of its tasks is throwing an exception, see e.g.
Hi Frank,
That WrappedReportHandler is the following (because we otherwise don't
have visibility about reports in our logs):
private static class WrappedReportHandler implements ReportHandler {
private final ReportHandler m_inner;
private final SnmpTracer m_snmpTracer =
Hi Peter,
You analysis matches mine. The problem is, that the
cancel returns true on my system and with my unit test in that case.
From reading the code, the cancel must return true in this
case, because the pending request is already scheduled at that time
which is ensured by the
Hi Peter,
Thank you for trying version 2.5.2, although it seems to be inexplicable
why the behavior changed.
There are no changes in 2.5.2 and 2.5.1 in the class Snmp.
Best regards,
Frank
Am 10.10.2016 um 13:27 schrieb Peter Verthez:
Traces now, for info:
2016-10-10 13:25:54,180 DEBUG
Traces now, for info:
2016-10-10 13:25:54,180 DEBUG
[JM-45-Ping-Ping-7]-[org.snmp4j.security.UsmUserTable] Adding user
verthezp_wrong2 =
UsmUser[secName=verthezp_wrong2,authProtocol=1.3.6.1.6.3.10.1.1.3,authPassphrase=12345678,privProtocol=null,privPassphrase=null,localizationEngineID=null]
Hi Peter,
Sorry, my statement in my previous message was wrong. Please ignore it,
because
setting the request-id field to 0 in a REPORT PDU is OK: If the request
was encrypted
the command responder would have no chance to decode the request-id field.
That's is why the command generator has
Hi Peter,
The command responder is not setting the request-id correctly in the
REPORT PDU.
This is causing the issue on the SNMP4J side. Nevertheless, SNMP4J
should behave more
robust and should call the response listener after the request times out.
I will add a corresponding unit test for
Ah, maybe I copied the wrong traces then and that is the source of the
confusion (we have a mix of SNMPv2 and v3 agents).
Let me check...
Thanks,
Peter.
On 6/10/2016 21:45, Frank Fock wrote:
Hi Peter,
The PDU that is send is a SNMPv2c GET request and not a v3 request.
So this cannot be an
Hi Frank,
The PDU instance is not used in another thread, only in this one. All
normal functionality works properly (we started to use async requests
1.5 years ago), except for this timeout due to a wrong security name
being used.I'm not sure whether that is a new regression or
something
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() {
Hi Frank,
Our code is simply:
ResponseListener respListener = new
ResponseListener() {
@Override
public void onResponse(ResponseEvent event) {
// canceling is required as per SNMP4J
documentation
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
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
13 matches
Mail list logo
