[SNMP4J] Timeouts in version 2.5.7+
Frank Fock
fock at agentpp.com
Thu Apr 12 21:28:20 CEST 2018
Hi Steffen,
That was probably too fast :-(. I made an error when merging from master branch to the 2.x release
which introduced the bug you mentioned below by three way merging some testing modifications into it.
In the master branch the code was/is correct.
I will create a 2.6.2 version that fixes that.
Best regards,
Frank
> On 12. Apr 2018, at 19:04, Steffen Brüntjen <Steffen.Bruentjen at macmon.eu> wrote:
>
> Hi Frank,
>
> that was fast! I've started running tests with the new version and until now it is working well. I reviewed the code change and I think, it works, but there's a minor bug:
>
> In my opinion, it should be "if (tm.isIdle())", not "if (!tm.isIdle())" in line 108.
>
> Also I'm not sure whether the loop in the synchronized block is helpful. You should maybe rather do something like this:
>
> synchronized (this) {
> // check again to avoid race conditions with the notify of the task manager
> for (TaskManager tm : taskManagers) {
> if (!tm.isIdle()) {
> tm.execute(task);
> return;
> }
> }
> try {
> wait(taskManagersBusyTimeoutMillis);
> } catch (InterruptedException ex) {
> handleInterruptedExceptionOnExecute(ex, task);
> }
> }
>
>
> Because now a WorkerTask could run into the synchronized block, finds a taskManager to be idle, then runs through the taskManagers (third time) and may find all taskManagers busy again.
>
> Thank you for your very quick fix!
>
> Best regards,
> Steffen Brüntjen
>
>
> -----Original Message-----
> From: Frank Fock [mailto:fock at agentpp.com]
> Sent: Dienstag, 10. April 2018 17:25
> To: Steffen Brüntjen <Steffen.Bruentjen at macmon.eu>
> Cc: snmp4j at agentpp.org
> Subject: Re: [SNMP4J] Timeouts in version 2.5.7+
>
> Hi Steffen,
>
> OK, many thanks for helping sorting this out. I support your analysis and will provide a fix a soon as possible.
>
> Best regards,
> Frank
>
>> On 10. Apr 2018, at 12:26, Steffen Brüntjen <Steffen.Bruentjen at macmon.eu> wrote:
>>
>> Hi Frank
>>
>>
>> I know that remote troubleshooting is annoying; that's why I was trying to provide as many details as possible. Anyways, with your last hint we're getting there! The while loop you mentioned is not exited, we can see that in the stack traces. Actually, the DefaultUDPTransportMapping thread remains forever in this state:
>>
>> "DefaultUDPTransportMapping_0.0.0.0/0" #35 daemon prio=5 os_prio=0 tid=0x00007f6829984800 nid=0x2a6d in Object.wait() [0x00007f67936fd000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool.execute(ThreadPool.java:103)
>> - locked <0x0000000088818548> (a org.snmp4j.util.ThreadPool)
>> at org.snmp4j.util.MultiThreadedMessageDispatcher.processMessage(MultiThreadedMessageDispatcher.java:162)
>> at org.snmp4j.transport.AbstractTransportMapping.fireProcessMessage(AbstractTransportMapping.java:76)
>> at org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:430)
>> at java.lang.Thread.run(Thread.java:745)
>>
>>
>> It is waiting for a notify that never comes:
>>
>> synchronized (this) {
>> try {
>> wait(); // line 103
>> } catch (InterruptedException ex) {
>> handleInterruptedExceptionOnExecute(ex, task);
>> }
>>
>>
>> I guess, here's a timing problem. Suppose, in this piece of code,
>>
>> public void execute(WorkerTask task) {
>> while (true) {
>> for (int i=0; i<taskManagers.size(); i++) {
>> TaskManager tm = taskManagers.get(i);
>> if ((respawnThreads) && (!tm.isAlive())) {
>> tm = new TaskManager(getTaskManagerName(name, i));
>> taskManagers.set(i, tm);
>> }
>> if (tm.isIdle()) {
>> try {
>> tm.execute(task);
>> return;
>> }
>> catch (IllegalStateException isex) {
>> // ignore
>> }
>> }
>> }
>> synchronized (this) {
>> try {
>> wait();
>> } catch (InterruptedException ex) {
>> handleInterruptedExceptionOnExecute(ex, task);
>> }
>> }
>> }
>> }
>>
>>
>> tm.isIdle() returns false for all task managers, because they are all working. In that case, the thread would start waiting for a notify by any of the task managers. Suppose moreover, the notify actually came from all running task managers right before this thread entered waiting status. execute() wouldn't return, in fact it would stay in line 103 (SNMP4J-2.5.7), and that's exactly what we can see in the stacktrace. In version 2.5.6, notify could not happen between tm.isIdle() and wait() because execute() was synchronized.
>>
>>
>> Best regards,
>> Steffen Brüntjen
>>
>>
>>
>> -----Original Message-----
>> From: Frank Fock [mailto:fock at agentpp.com]
>> Sent: Montag, 9. April 2018 20:59
>> To: Steffen Brüntjen <Steffen.Bruentjen at macmon.eu>
>> Cc: snmp4j at agentpp.org
>> Subject: Re: [SNMP4J] Timeouts in version 2.5.7+
>>
>> Hi Steffen,
>>
>> I understood the problem very well, but I am trying to find a possible cause.
>> In past, users have chosen a very low timeout because it worked - the system(s) answered very fast and SNMP4J timeout mechanism was not fast enough to timeout the request although the timeout value was lower than the effective response time.
>>
>> This behaviour then changed by some other timing side effect and all answers were timed out then.
>> I just wanted to sort this out, but you did not provide your timeout value though.
>>
>> As supporter it is very difficult to operate with too few facts.
>>
>> As you can see from the following code of the DefaultUdpTransportMapping class, the “Received…” log message must be printed out if something was received from the UDP port:
>>
>> public void run() {
>> DatagramSocket socketCopy = socket;
>> if (socketCopy != null) {
>> try {
>> socketCopy.setSoTimeout(getSocketTimeout());
>> if (receiveBufferSize > 0) {
>> socketCopy.setReceiveBufferSize(Math.max(receiveBufferSize,
>> maxInboundMessageSize));
>> }
>> if (logger.isDebugEnabled()) {
>> logger.debug("UDP receive buffer size for socket " +
>> getAddress() + " is set to: " +
>>
>> socketCopy.getReceiveBufferSize());
>> }
>> } catch (SocketException ex) {
>> logger.error(ex);
>> setSocketTimeout(0);
>> }
>> }
>> while (!stop) {
>> DatagramPacket packet = new DatagramPacket(buf, buf.length,
>> udpAddress.getInetAddress(),
>> udpAddress.getPort());
>> try {
>> socketCopy = socket;
>> ByteBuffer bis;
>> TransportStateReference stateReference =
>> new TransportStateReference(DefaultUdpTransportMapping.this, udpAddress, null,
>> SecurityLevel.undefined, SecurityLevel.undefined,
>> false, socketCopy);
>> try {
>> if (socketCopy == null) {
>> stop = true;
>> continue;
>> }
>> try {
>> socketCopy.receive(packet);
>> }
>> catch (SocketTimeoutException ste) {
>> continue;
>> }
>> bis = prepareInPacket(packet, buf, stateReference);
>> }
>> catch (InterruptedIOException iiox) {
>> if (iiox.bytesTransferred <= 0) {
>> continue;
>> }
>> bis = prepareInPacket(packet, buf, stateReference);
>> }
>> if (logger.isDebugEnabled()) {
>> logger.debug("Received message from "+packet.getAddress()+"/"+
>> packet.getPort()+
>> " with length "+packet.getLength()+": "+
>> new OctetString(packet.getData(), 0,
>> packet.getLength()).toHexString());
>> }
>> if (bis != null) {
>> fireProcessMessage(new UdpAddress(packet.getAddress(),
>> packet.getPort()), bis, stateReference);
>> }
>> }
>> catch (SocketTimeoutException stex) {
>> // ignore
>> }
>> catch (PortUnreachableException purex) {
>> synchronized (DefaultUdpTransportMapping.this) {
>> listener = null;
>> }
>> logger.error(purex);
>> if (logger.isDebugEnabled()) {
>> purex.printStackTrace();
>> }
>> if (SNMP4JSettings.isForwardRuntimeExceptions()) {
>> throw new RuntimeException(purex);
>> }
>> break;
>> }
>> catch (SocketException soex) {
>> if (!stop) {
>> logger.warn("Socket for transport mapping " + toString() + " error: " + soex.getMessage());
>> }
>> if (SNMP4JSettings.isForwardRuntimeExceptions()) {
>> stop = true;
>> throw new RuntimeException(soex);
>> }
>> else if (!stop) {
>> try {
>> DatagramSocket newSocket = renewSocketAfterException(soex, socketCopy);
>> if (newSocket == null) {
>> throw soex;
>> }
>> socket = newSocket;
>> } catch (SocketException e) {
>> stop = true;
>> socket = null;
>> logger.error("Socket renewal for transport mapping " + toString() +
>> " failed with: " + e.getMessage(), e);
>>
>> }
>> }
>> }
>> catch (IOException iox) {
>> logger.warn(iox);
>> if (logger.isDebugEnabled()) {
>> iox.printStackTrace();
>> }
>> if (SNMP4JSettings.isForwardRuntimeExceptions()) {
>> throw new RuntimeException(iox);
>> }
>> }
>> }
>> If that is not the case,
>>
>> (a) either Java is not able to receive UDP packets from that socket anymore (then none of the possible reasons is caused by the SNMP4J stack or a specific version of it)
>> (b) The while loop is exited.
>>
>> Possible reasons for (b) could be an API call or an uncaught exception within the while loop.
>>
>> Can you reproduce the issue with a simple MIB walk or an application where you ca share the log - at least the snippet between last successful answer processing and the first failure?
>>
>> Best regards,
>> Frank
>>
>>
>>
>> On 9. Apr 2018, at 15:19, Steffen Brüntjen <Steffen.Bruentjen at macmon.eu> wrote:
>>
>> Hi!
>>
>>
>> Is your timeout value big enough?
>>
>> It seems I couldn't make the problem clear, so once again from the beginning. I've been sending millions of millions SNMP queries over a long time, like months, with no problems. Then I replaced SNMP4J version 2.5.6 with version 2.5.7 (it can be any other newer release) and restarted the program. The program starts running fine again, but only for some comparatively short amount of time (sometimes 10 minutes, sometimes 2 days). From the moment on, when the problem arises, NO more SNMP packets are received at all. There's not a single SNMP request that results in something else but a timeout. I made no configuration changes like timeouts/retries, no changes in the network, none of the 200 devices change and no one has access to the machine. Consequently, when I restart the program, it runs fine again. So I bet a too low timeout can't be the problem. As an example here's my last test. I extracted all data from SNMP4J log messages:
>>
>> 2018-04-05 10:43 Program starts
>> 2018-04-05 10:43 First outgoing SNMP request
>> 2018-04-05 22:23 Last incoming message
>> 2018-04-09 ..... Program is still running (until today)
>>
>> 4,994,621 sent messages from 2018-04-05 10:43 to 22:23
>> 4,992,120 received msgs from 2018-04-05 10:43 to 22:23
>> 53,323 sent messages from 2018-04-05 22:23 to now
>> 0 received msgs from 2018-04-05 22:23 to now
>>
>> (The different number of outgoing requests per amount of time comes from the fact I wrote in my first mail: The program queries the sysObjectId and then - if successful - more OIDs. If the sysObjectId can't be queried, the rest of communication doesn't take place.)
>>
>>
>>
>> I do not see any differences in the stacktraces, do I miss something?
>>
>> In your last mail you wrote, that "From the stack trace it seems that there is no idle TaskManager in your ThreadPool for the MultiThreadMessageDispatcher left.". So with the two identical stack traces I was trying to point out that there's no indication of a missing TaskManager thread.
>>
>>
>> Best regards and thanks,
>> Steffen Brüntjen
>>
>>
>>
>>
>> -----Original Message-----
>> From: Frank Fock [mailto:fock at agentpp.com]
>> Sent: Freitag, 6. April 2018 15:40
>> To: Steffen Brüntjen <Steffen.Bruentjen at macmon.eu>
>> Cc: snmp4j at agentpp.org
>> Subject: Re: [SNMP4J] Timeouts in version 2.5.7+
>>
>> Is your timeout value big enough?
>> I do not see any differences in the stacktraces, do I miss something?
>>
>>
>>
>> Am 06.04.2018 um 14:15 schrieb Steffen Brüntjen <Steffen.Bruentjen at macmon.eu>:
>>
>> Hi Frank
>>
>> Mmh, I don't think it's because of uncaught exceptions (at least not outside of SNMP4J). SNMP packets are continued to be sent out normally, the responses are received by kernel but not "recognized" by SNMP4J (see tcpdump output). I get normal timeouts as if the devices wouldn't respond any more (but they do). I reproduced the problem once again with TRACE logging enabled. The SNMP4J logs appear to be very normal, except that there are no more "Received message from ... with length ...: ..." messages any more (DefaultUdpTransportMapping.java:409). Here are the different types of log messages after problem occurs (in random order):
>>
>> Sending message to .../161 with length 43: ... | (DefaultUdpTransportMapping.java:112)
>> Removed pending request with handle: PduHandle[...] | (Snmp.java:995)
>> Request timed out: ... | (Snmp.java:1900)
>> Running pending sync request with handle PduHandle[...] and retry count left 1 | (Snmp.java:1808)
>>
>>
>> The stacktraces look the same when everything is running fine:
>>
>> "snmp.3" #39 prio=5 os_prio=0 tid=0x00007f682a81a000 nid=0x2a71 in Object.wait() [0x00007f67932f9000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x0000000088861810> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>> "snmp.2" #38 prio=5 os_prio=0 tid=0x00007f682a818000 nid=0x2a70 in Object.wait() [0x00007f67933fa000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x0000000088861a20> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>> "snmp.1" #37 prio=5 os_prio=0 tid=0x00007f6829986800 nid=0x2a6f in Object.wait() [0x00007f67934fb000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x0000000088861c30> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>> "snmp.0" #36 prio=5 os_prio=0 tid=0x00007f6829988800 nid=0x2a6e in Object.wait() [0x00007f67935fc000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x0000000088861e40> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>>
>> Here are the stacktraces after problem starts:
>>
>> "snmp.3" #39 prio=5 os_prio=0 tid=0x00007f682a81a000 nid=0x2a71 in Object.wait() [0x00007f67932f9000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x00000000888185a0> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>> "snmp.2" #38 prio=5 os_prio=0 tid=0x00007f682a818000 nid=0x2a70 in Object.wait() [0x00007f67933fa000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x00000000888187b0> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>> "snmp.1" #37 prio=5 os_prio=0 tid=0x00007f6829986800 nid=0x2a6f in Object.wait() [0x00007f67934fb000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x00000000888189c0> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>> "snmp.0" #36 prio=5 os_prio=0 tid=0x00007f6829988800 nid=0x2a6e in Object.wait() [0x00007f67935fc000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x0000000088818bd0> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>>
>>
>> Best regards
>> Steffen Brüntjen
>>
>>
>> -----Original Message-----
>> From: Frank Fock [mailto:fock at agentpp.com]
>> Sent: Mittwoch, 4. April 2018 00:54
>> To: Steffen Brüntjen <Steffen.Bruentjen at macmon.eu>
>> Cc: snmp4j at agentpp.org
>> Subject: Re: [SNMP4J] Timeouts in version 2.5.7+
>>
>> Hi Steffen,
>>
>> From the stack trace it seems that there is no idle TaskManager in your ThreadPool for the MultiThreadMessageDispatcher left.
>> Maybe all TaskManagers died because of exceptions?
>>
>> You can simply use the DefaultMessageDispatcher in your case. I do not expect advantages from the multi-threaded variant. Maybe you can find the root cause easier with the simple message dispatcher.
>>
>> Best regards,
>> Frank
>>
>>
>>
>> On 3. Apr 2018, at 13:26, Steffen Brüntjen <Steffen.Bruentjen at macmon.eu> wrote:
>>
>> Hi Frank
>>
>>
>> Thanks for your reply. I don't reuse PDUs. In case of SNMPv2c, the effective statements would be:
>>
>> PDU pdu = new PDU();
>> pdu.setType(PDU.GET);
>> pdu.add(new VariableBinding(...));
>> ResponseEvent responseEvent = snmp.send(pdu, target); // timeout
>>
>> I believe the PDU request IDs will be coming from this code in MessageDispatcherImpl:
>>
>> protected PduHandle createPduHandle() {
>> return new PduHandle(getNextRequestID());
>> }
>>
>>
>> There's only one static snmp instance for all targets, I read somewhere that this is the preferred implementation.
>>
>>
>> I'am also able to remote debug the program, but I wouldn't know where to look at. Also, it's a bit of extra work and it will take a while, but it's possible.
>>
>>
>> Best regards,
>> Steffen
>>
>>
>> -----Original Message-----
>> From: Frank Fock [mailto:fock at agentpp.com]
>> Sent: Sonntag, 1. April 2018 08:23
>> To: Steffen Brüntjen <Steffen.Bruentjen at macmon.eu>
>> Cc: snmp4j at agentpp.org
>> Subject: Re: [SNMP4J] Timeouts in version 2.5.7+
>>
>> Hi Steffen,
>>
>> There was no change on the DefaultUdpTransportMapping between 2.5.6 and 2.5.7, thus I assume that behaviour change is a side effect of some other changes. SNMP4J is no a bit faster.
>> Have you checked your code for race conditions?
>> When you use Snmp.send, how do you create the request IDs of the PDUs?
>>
>> Also reusing the PDU objects before the request is finished might cause this issue.
>>
>> Best regards,
>> Frank
>>
>>
>> On 16. Mar 2018, at 12:14, Steffen Brüntjen <Steffen.Bruentjen at macmon.eu> wrote:
>>
>> Hi!
>>
>> I'm using SNMP4J for monitoring around 200 devices. It has been running stably for months. Now I found a problem in the latest releases: When my process runs for a couple of hours (sometimes days), after some time SNMP4J returns nothing but timeouts. My program initially uses Snmp.send() and TableUtils (I think, this doesn't matter). After the problem shows up once, all my program effectively does is querying the SysObjectIds (because this already results in timeouts):
>>
>> org.snmp4j.Snmp.send(get(SnmpV2Mib.sysObjectID), target)
>>
>>
>> Some of the targets are community targets, some are user targets, but I get timeouts for all devices. I repeated testing with only community targets resulting in the same behavior. I tracked down the problem to release 2.5.7. The previous version 2.5.6 works without problems, all releases starting with 2.5.7 show the problem. I also analyzed the SNMP packages using tcpdump. The devices send their answers quickly, the packets don't look any special. It seems that SNMP4J doesn't receive, recognize or process the UDP packets.
>>
>> Can you reproduce the problem? Does anyone see problems in source code changes from 2.5.6 to 2.5.7?
>>
>> Best regards
>> Steffen Brüntjen
>>
>>
>>
>> Here are some stacktraces at the time the problem exists:
>>
>> "DefaultUDPTransportMapping_0.0.0.0/162" #72 daemon prio=5 os_prio=0 tid=0x00007fa0ac00a000 nid=0x4433 runnable [0x00007fa08b4f3000]
>> java.lang.Thread.State: RUNNABLE
>> at java.net.PlainDatagramSocketImpl.receive0(Native Method)
>> - locked <0x0000000089977c28> (a java.net.PlainDatagramSocketImpl)
>> at java.net.AbstractPlainDatagramSocketImpl.receive(AbstractPlainDatagramSocketImpl.java:143)
>> - locked <0x0000000089977c28> (a java.net.PlainDatagramSocketImpl)
>> at java.net.DatagramSocket.receive(DatagramSocket.java:812)
>> - locked <0x0000000089b2b3a8> (a java.net.DatagramPacket)
>> - locked <0x0000000089977c78> (a java.net.DatagramSocket)
>> at org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:397)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> "DefaultUDPTransportMapping_0.0.0.0/0" #33 daemon prio=5 os_prio=0 tid=0x00007fa126c9d800 nid=0x440c in Object.wait() [0x00007fa0b60f1000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool.execute(ThreadPool.java:103)
>> - locked <0x00000000883cde50> (a org.snmp4j.util.ThreadPool)
>> at org.snmp4j.util.MultiThreadedMessageDispatcher.processMessage(MultiThreadedMessageDispatcher.java:162)
>> at org.snmp4j.transport.AbstractTransportMapping.fireProcessMessage(AbstractTransportMapping.java:76)
>> at org.snmp4j.transport.DefaultUdpTransportMapping$ListenThread.run(DefaultUdpTransportMapping.java:430)
>> at java.lang.Thread.run(Thread.java:745)
>>
>> "snmp.3" #37 prio=5 os_prio=0 tid=0x00007fa125a38000 nid=0x4410 in Object.wait() [0x00007fa0b5ced000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x00000000883ddeb8> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>> "snmp.2" #36 prio=5 os_prio=0 tid=0x00007fa126ca1800 nid=0x440f in Object.wait() [0x00007fa0b5dee000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x00000000883de0c8> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>> "snmp.1" #35 prio=5 os_prio=0 tid=0x00007fa126ca0800 nid=0x440e in Object.wait() [0x00007fa0b5eef000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x00000000883de2d8> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>> "snmp.0" #34 prio=5 os_prio=0 tid=0x00007fa126ca0000 nid=0x440d in Object.wait() [0x00007fa0b5ff0000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x00000000883de4e8> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>> "trap.0" #71 prio=5 os_prio=0 tid=0x00007fa0ac004000 nid=0x4432 in Object.wait() [0x00007fa08b5f4000]
>> java.lang.Thread.State: WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at java.lang.Object.wait(Object.java:502)
>> at org.snmp4j.util.ThreadPool$TaskManager.run(ThreadPool.java:275)
>> - locked <0x0000000089979080> (a org.snmp4j.util.ThreadPool$TaskManager)
>>
>>
>> And then there are some monitoring threads that send SNMP queries:
>>
>> "mon-001" #43 prio=5 os_prio=0 tid=0x00007fa0c000c000 nid=0x4416 in Object.wait() [0x00007fa0b52e7000]
>> java.lang.Thread.State: TIMED_WAITING (on object monitor)
>> at java.lang.Object.wait(Native Method)
>> at org.snmp4j.Snmp.send(Snmp.java:991)
>> - locked <0x00000000fdc0c6e0> (a org.snmp4j.Snmp$SyncResponseListener)
>> at org.snmp4j.Snmp.send(Snmp.java:963)
>> at org.snmp4j.Snmp.send(Snmp.java:928)
>> at [...]
>>
>>
>>
>> And here's some non-binary tcpdump output:
>>
>> 12:05:49.820810 IP 192.168.101.211.57522 > 10.100.7.204.snmp: GetRequest(28) system.sysObjectID.0
>> E..G.. at .@. at ...e.
>> d.......38.0).....public..../.........0.0...+.........
>> 12:05:49.821321 IP 10.100.7.204.snmp > 192.168.101.211.57522: GetResponse(37) system.sysObjectID.0=E:cisco.1.614
>> E..P.. at .@.SW
>> d....e......<..02.....public.%../.........0.0...+........ +.... ..f
>> ^C
>> _______________________________________________
>> SNMP4J mailing list
>> SNMP4J at agentpp.org
>> https://oosnmp.net/mailman/listinfo/snmp4j
>>
>>
>>
>>
>
More information about the SNMP4J
mailing list