eed to
do this workaround?
In any case, thanks for all your help!
Best regards,
Peter.
On 13/10/2016 8:56, Peter Verthez wrote:
Hi Frank,
That WrappedReportHandler is the following (because we otherwise don't
have visibility about reports in our logs):
private static class WrappedRep
:43, Frank Fock wrote:
Hi Peter,
I just seem to have found the cause: The class
"SecureSnmpFactory$WrappedReportHandler" is not part of SNMP4J
and so I assume that this implementation is causing the issue.
Best regards,
Frank
Am 12.10.2016 um 16:29 schrieb Peter Verthez:
Hi Frank
org.snmp4j.event.ResponseEvent[source=org.snmp4j.Snmp@dbb54af]
2016-10-10 13:26:06,189 DEBUG [SNMP4J Timer]-[org.snmp4j.Snmp]
Cancelling pending request with handle PduHandle[922855848]
Best regards,
Peter.
On 10/10/2016 13:25, Peter Verthez wrote:
Hi Frank,
I've tried now with SNMP4J 2.5.2 (downloaded
he command responder.
If locally unknown, a exception is thrown during the send call.
Best regards,
Frank
Am 06.10.2016 um 09:45 schrieb Peter Verthez:
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 req
), which would corrupt the pending request management.
Best regards,
Frank
Am 05.10.2016 um 08:14 schrieb Peter Verthez:
Hi Frank,
The call of the send method was in the last line of my code snippet:
session is an Snmp object.
Best regards,
Peter.
On 4/10/2016 20:12, Frank Fock wrote:
Hi
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
]-[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 PduHandle[1071987217]
Best regards,
Peter.
--
Peter Verthez
___
SNMP4J mailing list
SNMP4J@agentpp.org
https
();
// because we are using a weak hash map for the cache, we need
to null out
// our key from the entry.
entry.setPduHandle(null);
entries.put(key, entry);
return SnmpConstants.SNMP_MP_OK;
}
Best regards,
Frank
Am 27.10.2014 13:12, schrieb Peter Verthez:
Hi
Hi Frank,
We have now tried with both SNMP4J 2.3.0 and 2.3.1 and we're facing the
same problem.
Can you investigate this? Is there any more information we could provide?
Best regards,
Peter.
On 24/10/2014 8:17, Peter Verthez wrote:
OK, thanks, we'll try that (we are on the latest version
thought this improvement would not have any effect
on your issue,
but I am not 100% sure. I will have to exeactly analyze the
request/response sequences
to be sure.
Best regards,
Frank
Am 27.10.2014 08:01, schrieb Peter Verthez:
Hi Frank,
We have now tried with both SNMP4J 2.3.0 and 2.3.1
conditions
in the Snmp class regarding retries and the PduHandleCallback. The
current implementation
seems to be OK regarding handling of the Message IDs and the MPv3
Cache WeakHashMap.
Best regards,
Frank
Am 23.10.2014 12:34, schrieb Peter Verthez:
Hi Frank,
One of our customers has reported
a view on the overall design: maybe there
are references elsewhere.
Could you investigate this issue?
Thanks,
Peter.
--
Peter Verthez
Systems Engineer Network Mgt.
Alcatel-Lucent Bell NV
___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net
/snmp4j
--
Peter Verthez
Systems Engineer Network Mgt.
Alcatel-Lucent Bell NV
___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j
that
argument, but it is clear that SNMP4J does not do that.
Could you explain your view on this?
Best regards,
Peter.
--
Peter Verthez
Systems Engineer Network Mgt.
Tel: (+32) 3 240 84 50 | Alcanet:
Fax: (+32) 3 240 84 59 | (6)2605
Alcatel-Lucent Bell NV
Copernicuslaan 50, 2018 Antwerp
.
--
Peter Verthez
___
SNMP4J mailing list
SNMP4J@agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j
, but cached information for the msgID could not
be found
2009-12-09 15:20:30,912 WARN
[DefaultUDPTransportMapping_172.31.110.52/0]-[org.snmp4j.MessageDispatcherImpl]
noError
Best regards,
Peter.
--
Peter Verthez
Systems Engineer Network Mgt.
Alcatel-Lucent Bell NV
16 matches
Mail list logo
