[SNMP4J] Possible concurrency bug in snmp4j ?
Hi..i'm using snm4j 2.4.3.
Is it possible that just when snmp4j closes a connection (due to timeout, or
remote closing) and it's trying to addRegistration causing to throw an
exception, is it possible that snmp4j can no longer establish connection?
Below is a small log of a sample client I'm doing , which does interval every 5
seconds, furthermore it's target.setTimeout is also set to 5 seconds, to
emulate the bug (which actually happens upon remote close)
You can see that subsequent attempts simply try to connect but don't' send
anything..
Mon Feb 12 18:10:37 IST 2018 Sending message
Looking up connection for destination '192.168.97.21/162' returned:
SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[addr=qa-mv-0640.corp.aeroscout.com/192.168.97.21,port=162,localport=51072],lastUse=Mon
Mar 09 04:30:03 IST 1970,readBufferPosition=-1]
{192.168.97.21/162=SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[addr=qa-mv-0640.corp.aeroscout.com/192.168.97.21,port=162,localport=51072],lastUse=Mon
Mar 09 04:30:03 IST 1970,readBufferPosition=-1]}
Waking up selector for new message
Socket has not been used for 10002 milliseconds, closing it
Socket to 192.168.97.21/162 closed due to timeout
Adding operation 8 for:
SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
Mar 09 04:30:13 IST 1970,readBufferPosition=-1]
java.nio.channels.ClosedChannelException
Firing transport state event:
org.snmp4j.transport.TransportStateEvent[source=org.snmp4j.transport.DefaultTcpTransportMapping@1d6c6de8,peerAddress=192.168.97.21/162,newState=4,cancelled=false,causingException=java.nio.channels.ClosedChannelException]
State changed to Closed Peer address 192.168.97.21/162
Exception in thread "DefaultTCPTransportMapping_192.168.60.80/0"
java.lang.RuntimeException: java.nio.channels.ClosedChannelException
at
org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.processPending(DefaultTcpTransportMapping.java:697)
at
org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.run(DefaultTcpTransportMapping.java:893)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.nio.channels.ClosedChannelException
at
java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:197)
at
org.snmp4j.transport.DefaultTcpTransportMapping$SocketEntry.addRegistration(DefaultTcpTransportMapping.java:433)
at
org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.processPending(DefaultTcpTransportMapping.java:658)
... 2 more
Mon Feb 12 18:10:47 IST 2018 Sending message
Looking up connection for destination '192.168.97.21/162' returned: null
{}
Socket for address '192.168.97.21/162' is closed, opening it...
Trying to connect to 192.168.97.21/162
Mon Feb 12 18:10:57 IST 2018 Sending message
Looking up connection for destination '192.168.97.21/162' returned:
SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
Mar 09 04:30:23 IST 1970,readBufferPosition=-1]
{192.168.97.21/162=SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
Mar 09 04:30:23 IST 1970,readBufferPosition=-1]}
Socket for address '192.168.97.21/162' is closed, opening it...
Trying to connect to 192.168.97.21/162
Mon Feb 12 18:11:07 IST 2018 Sending message
Looking up connection for destination '192.168.97.21/162' returned:
SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
Mar 09 04:30:33 IST 1970,readBufferPosition=-1]
{192.168.97.21/162=SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
Mar 09 04:30:33 IST 1970,readBufferPosition=-1]}
Socket for address '192.168.97.21/162' is closed, opening it...
___
SNMP4J mailing list
SNMP4J@agentpp.org
https://oosnmp.net/mailman/listinfo/snmp4j
Re: [SNMP4J] Possible concurrency bug in snmp4j ?
Thanks, I'll try that , I'm trying to access the bug system, but I can't find
it
The real issue I'm encountering which I don't know the cause is that the snmp4j
tries to send messages, trying to connect , but simply doesn't, I did a thread
dump and it seems to be stuck on the select method no matter what
"DefaultTCPTransportMapping_192.168.60.80/0" #75906 daemon prio=5 os_prio=0
tid=0x7f4748e75000 nid=0x79e5 runnable [0x7f4733768000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0x0007042019f8> (a sun.nio.ch.Util$3)
- locked <0x0007042019e8> (a java.util.Collections$UnmodifiableSet)
- locked <0x000704201a08> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
at
org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.run(DefaultTcpTransportMapping.java:786)
at java.lang.Thread.run(Thread.java:745)
there's nothing on tcpdump, using a separate snmp4j on shell on the same
machine is able to connect to the same remote machine,
but still:
2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Looking up
connection for destination '192.168.56.1/162' returned:
SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
Mar 09 07:06:25 IST 1970,readBufferPosition=-1]
2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping -
{192.168.56.1/162=SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
Mar 09 07:06:25 IST 1970,readBufferPosition=-1]}
2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Socket for address
'192.168.56.1/162' is closed, opening it...
2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Trying to connect to
192.168.56.1/162
I see that "trying to connect to" is invoked the wakeup, so that must means the
.select is released, but returns no keys, can there be any reason for that?
-Original Message-
From: Frank Fock [mailto:f...@agentpp.com]
Sent: Monday, February 12, 2018 8:45 PM
To: Maayan, Elhanan <elhanan.maa...@sbdinc.com>
Cc: snmp4j@agentpp.org
Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
*External Message, please be cautious.*
Hi Elhanan,
Please upgrade to SNMP4J 2.5.11 to fix this issue.
Best regards
Frank
> Am 12.02.2018 um 18:05 schrieb Maayan, Elhanan <elhanan.maa...@sbdinc.com>:
>
> Hi..i'm using snm4j 2.4.3.
>
> Is it possible that just when snmp4j closes a connection (due to timeout, or
> remote closing) and it's trying to addRegistration causing to throw an
> exception, is it possible that snmp4j can no longer establish connection?
>
>
>
> Below is a small log of a sample client I'm doing , which does interval every
> 5 seconds, furthermore it's target.setTimeout is also set to 5 seconds, to
> emulate the bug (which actually happens upon remote close)
>
> You can see that subsequent attempts simply try to connect but don't' send
> anything..
>
>
>
> Mon Feb 12 18:10:37 IST 2018 Sending message
>
> Looking up connection for destination '192.168.97.21/162' returned:
> SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[addr=qa-mv-0640.corp.aeroscout.com/192.168.97.21,port=162,localport=51072],lastUse=Mon
> Mar 09 04:30:03 IST 1970,readBufferPosition=-1]
>
> {192.168.97.21/162=SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[addr=qa-mv-0640.corp.aeroscout.com/192.168.97.21,port=162,localport=51072],lastUse=Mon
> Mar 09 04:30:03 IST 1970,readBufferPosition=-1]}
>
> Waking up selector for new message
>
> Socket has not been used for 10002 milliseconds, closing it
>
> Socket to 192.168.97.21/162 closed due to timeout
>
> Adding operation 8 for:
> SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[unconnected],lastUse=Mon
> Mar 09 04:30:13 IST 1970,readBufferPosition=-1]
>
> java.nio.channels.ClosedChannelException
>
> Firing transport state event:
> org.snmp4j.transport.TransportStateEvent[source=org.snmp4j.transport.DefaultTcpTransportMapping@1d6c6de8,peerAddress=192.168.97.21/162,newState=4,cancelled=false,causingException=java.nio.channels.ClosedChannelException]
>
> State changed to Closed Peer address 192.168.97.21/162
>
> Exception in thread "DefaultTCPTransportMapping_192.168.60.80/0"
> java.lang.RuntimeException: java.nio.channels.ClosedChannelException
>
>at
> org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.processPendin
Re: [SNMP4J] Possible concurrency bug in snmp4j ?
so 2.5.11 won't help? Any workaround?
Get Outlook for Android<https://aka.ms/ghei36>
From: Frank Fock <f...@agentpp.com>
Sent: Tuesday, February 13, 2018 11:51:23 AM
To: Maayan, Elhanan
Cc: snmp4j@agentpp.org
Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
*External Message, please be cautious.*
The immediate reconnection issue (TCP) to the same address and port (SFJ-164)
has been fixed in SNMP4J 2.6.0 which is available as SNAPSHOT.
See also the mailing list archive around January 27th.
The ticket system is available for users with support contract.
Best regards,
Frank
> On 12. Feb 2018, at 19:53, Maayan, Elhanan <elhanan.maa...@sbdinc.com> wrote:
>
> Thanks, I'll try that , I'm trying to access the bug system, but I can't find
> it
>
> The real issue I'm encountering which I don't know the cause is that the
> snmp4j tries to send messages, trying to connect , but simply doesn't, I did
> a thread dump and it seems to be stuck on the select method no matter what
>
> "DefaultTCPTransportMapping_192.168.60.80/0" #75906 daemon prio=5 os_prio=0
> tid=0x7f4748e75000 nid=0x79e5 runnable [0x7f4733768000]
> java.lang.Thread.State: RUNNABLE
>at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
>at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>- locked <0x0007042019f8> (a sun.nio.ch.Util$3)
>- locked <0x0007042019e8> (a java.util.Collections$UnmodifiableSet)
>- locked <0x000704201a08> (a sun.nio.ch.EPollSelectorImpl)
>at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>at
> org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.run(DefaultTcpTransportMapping.java:786)
>at java.lang.Thread.run(Thread.java:745)
>
> there's nothing on tcpdump, using a separate snmp4j on shell on the same
> machine is able to connect to the same remote machine,
>
> but still:
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Looking up
> connection for destination '192.168.56.1/162' returned:
> SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
> Mar 09 07:06:25 IST 1970,readBufferPosition=-1]
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping -
> {192.168.56.1/162=SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
> Mar 09 07:06:25 IST 1970,readBufferPosition=-1]}
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Socket for address
> '192.168.56.1/162' is closed, opening it...
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Trying to connect
> to 192.168.56.1/162
>
>
> I see that "trying to connect to" is invoked the wakeup, so that must means
> the .select is released, but returns no keys, can there be any reason for
> that?
>
>
>
>
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com]
> Sent: Monday, February 12, 2018 8:45 PM
> To: Maayan, Elhanan <elhanan.maa...@sbdinc.com>
> Cc: snmp4j@agentpp.org
> Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
>
> *External Message, please be cautious.*
>
> Hi Elhanan,
>
> Please upgrade to SNMP4J 2.5.11 to fix this issue.
>
> Best regards
> Frank
>
>> Am 12.02.2018 um 18:05 schrieb Maayan, Elhanan <elhanan.maa...@sbdinc.com>:
>>
>> Hi..i'm using snm4j 2.4.3.
>>
>> Is it possible that just when snmp4j closes a connection (due to timeout, or
>> remote closing) and it's trying to addRegistration causing to throw an
>> exception, is it possible that snmp4j can no longer establish connection?
>>
>>
>>
>> Below is a small log of a sample client I'm doing , which does interval
>> every 5 seconds, furthermore it's target.setTimeout is also set to 5
>> seconds, to emulate the bug (which actually happens upon remote close)
>>
>> You can see that subsequent attempts simply try to connect but don't' send
>> anything..
>>
>>
>>
>> Mon Feb 12 18:10:37 IST 2018 Sending message
>>
>> Looking up connection for destination '192.168.97.21/162' returned:
>> SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[addr=qa-mv-0640.corp.aeroscout.com/192.168.97.21,port=162,localport=51072],lastUse=Mon
>> Mar 09 04:30:03 IST 1970,readBufferPosition=-1]
>>
>> {192.168.97.21/162=SocketEntry[peerAddress=192.168.97.21/162,socket=Socket[addr=qa-mv-0640.corp.aerosc
Re: [SNMP4J] Possible concurrency bug in snmp4j ?
Thanks, do you have any timeline regarding 2.6?
From: Frank Fock [mailto:f...@agentpp.com]
Sent: Tuesday, February 13, 2018 7:15 PM
To: Maayan, Elhanan <elhanan.maa...@sbdinc.com>
Cc: snmp4j@agentpp.org
Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
*External Message, please be cautious.*
2.5.11 might already solve the problem, that depends on your usage profile.
The work around would be to apply the 2.6.0 DefaultTcpMapping sources to your
version, if you do not like to use/wait for that version.
On 13. Feb 2018, at 10:53, Maayan, Elhanan
<elhanan.maa...@sbdinc.com<mailto:elhanan.maa...@sbdinc.com>> wrote:
so 2.5.11 won't help? Any workaround?
Get Outlook for Android<https://aka.ms/ghei36>
From: Frank Fock <f...@agentpp.com<mailto:f...@agentpp.com>>
Sent: Tuesday, February 13, 2018 11:51:23 AM
To: Maayan, Elhanan
Cc: snmp4j@agentpp.org<mailto:snmp4j@agentpp.org>
Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
*External Message, please be cautious.*
The immediate reconnection issue (TCP) to the same address and port (SFJ-164)
has been fixed in SNMP4J 2.6.0 which is available as SNAPSHOT.
See also the mailing list archive around January 27th.
The ticket system is available for users with support contract.
Best regards,
Frank
> On 12. Feb 2018, at 19:53, Maayan, Elhanan
> <elhanan.maa...@sbdinc.com<mailto:elhanan.maa...@sbdinc.com>> wrote:
>
> Thanks, I'll try that , I'm trying to access the bug system, but I can't find
> it
>
> The real issue I'm encountering which I don't know the cause is that the
> snmp4j tries to send messages, trying to connect , but simply doesn't, I did
> a thread dump and it seems to be stuck on the select method no matter what
>
> "DefaultTCPTransportMapping_192.168.60.80/0" #75906 daemon prio=5 os_prio=0
> tid=0x7f4748e75000 nid=0x79e5 runnable [0x7f4733768000]
> java.lang.Thread.State: RUNNABLE
>at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
>at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>- locked <0x0007042019f8> (a sun.nio.ch.Util$3)
>- locked <0x0007042019e8> (a java.util.Collections$UnmodifiableSet)
>- locked <0x000704201a08> (a sun.nio.ch.EPollSelectorImpl)
>at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>at
> org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.run(DefaultTcpTransportMapping.java:786)
>at java.lang.Thread.run(Thread.java:745)
>
> there's nothing on tcpdump, using a separate snmp4j on shell on the same
> machine is able to connect to the same remote machine,
>
> but still:
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Looking up
> connection for destination '192.168.56.1/162' returned:
> SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
> Mar 09 07:06:25 IST 1970,readBufferPosition=-1]
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping -
> {192.168.56.1/162=SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
> Mar 09 07:06:25 IST 1970,readBufferPosition=-1]}
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Socket for address
> '192.168.56.1/162' is closed, opening it...
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Trying to connect
> to 192.168.56.1/162
>
>
> I see that "trying to connect to" is invoked the wakeup, so that must means
> the .select is released, but returns no keys, can there be any reason for
> that?
>
>
>
>
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com]
> Sent: Monday, February 12, 2018 8:45 PM
> To: Maayan, Elhanan
> <elhanan.maa...@sbdinc.com<mailto:elhanan.maa...@sbdinc.com>>
> Cc: snmp4j@agentpp.org<mailto:snmp4j@agentpp.org>
> Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
>
> *External Message, please be cautious.*
>
> Hi Elhanan,
>
> Please upgrade to SNMP4J 2.5.11 to fix this issue.
>
> Best regards
> Frank
>
>> Am 12.02.2018 um 18:05 schrieb Maayan, Elhanan
>> <elhanan.maa...@sbdinc.com<mailto:elhanan.maa...@sbdinc.com>>:
>>
>> Hi..i'm using snm4j 2.4.3.
>>
>> Is it possible that just when snmp4j closes a connection (due to timeout, or
>> remote closing) and it's trying to addRegistration causing to throw an
>> exception, is it possible that snmp4j can no longer establish connectio
Re: [SNMP4J] Possible concurrency bug in snmp4j ?
Hi, Is there a delay in release? I' rather not try the dev snapshot if
possible..
Get Outlook for Android<https://aka.ms/ghei36>
From: Frank Fock <f...@agentpp.com>
Sent: Wednesday, February 14, 2018 11:08:37 AM
To: Maayan, Elhanan
Cc: snmp4j@agentpp.org
Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
*External Message, please be cautious.*
2.6.0 will be released next week.
Am 13.02.2018 um 18:15 schrieb Maayan, Elhanan
<elhanan.maa...@sbdinc.com<mailto:elhanan.maa...@sbdinc.com>>:
Thanks, do you have any timeline regarding 2.6?
From: Frank Fock [mailto:f...@agentpp.com]
Sent: Tuesday, February 13, 2018 7:15 PM
To: Maayan, Elhanan
<elhanan.maa...@sbdinc.com<mailto:elhanan.maa...@sbdinc.com>>
Cc: snmp4j@agentpp.org<mailto:snmp4j@agentpp.org>
Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
*External Message, please be cautious.*
2.5.11 might already solve the problem, that depends on your usage profile.
The work around would be to apply the 2.6.0 DefaultTcpMapping sources to your
version, if you do not like to use/wait for that version.
On 13. Feb 2018, at 10:53, Maayan, Elhanan
<elhanan.maa...@sbdinc.com<mailto:elhanan.maa...@sbdinc.com>> wrote:
so 2.5.11 won't help? Any workaround?
Get Outlook for Android<https://aka.ms/ghei36>
From: Frank Fock <f...@agentpp.com<mailto:f...@agentpp.com>>
Sent: Tuesday, February 13, 2018 11:51:23 AM
To: Maayan, Elhanan
Cc: snmp4j@agentpp.org<mailto:snmp4j@agentpp.org>
Subject: Re: [SNMP4J] Possible concurrency bug in snmp4j ?
*External Message, please be cautious.*
The immediate reconnection issue (TCP) to the same address and port (SFJ-164)
has been fixed in SNMP4J 2.6.0 which is available as SNAPSHOT.
See also the mailing list archive around January 27th.
The ticket system is available for users with support contract.
Best regards,
Frank
> On 12. Feb 2018, at 19:53, Maayan, Elhanan
> <elhanan.maa...@sbdinc.com<mailto:elhanan.maa...@sbdinc.com>> wrote:
>
> Thanks, I'll try that , I'm trying to access the bug system, but I can't find
> it
>
> The real issue I'm encountering which I don't know the cause is that the
> snmp4j tries to send messages, trying to connect , but simply doesn't, I did
> a thread dump and it seems to be stuck on the select method no matter what
>
> "DefaultTCPTransportMapping_192.168.60.80/0" #75906 daemon prio=5 os_prio=0
> tid=0x7f4748e75000 nid=0x79e5 runnable [0x7f4733768000]
> java.lang.Thread.State: RUNNABLE
>at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
>at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>- locked <0x0007042019f8> (a sun.nio.ch.Util$3)
>- locked <0x0007042019e8> (a java.util.Collections$UnmodifiableSet)
>- locked <0x000704201a08> (a sun.nio.ch.EPollSelectorImpl)
>at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>at
> org.snmp4j.transport.DefaultTcpTransportMapping$ServerThread.run(DefaultTcpTransportMapping.java:786)
>at java.lang.Thread.run(Thread.java:745)
>
> there's nothing on tcpdump, using a separate snmp4j on shell on the same
> machine is able to connect to the same remote machine,
>
> but still:
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Looking up
> connection for destination '192.168.56.1/162' returned:
> SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
> Mar 09 07:06:25 IST 1970,readBufferPosition=-1]
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping -
> {192.168.56.1/162=SocketEntry[peerAddress=192.168.56.1/162,socket=Socket[unconnected],lastUse=Mon
> Mar 09 07:06:25 IST 1970,readBufferPosition=-1]}
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Socket for address
> '192.168.56.1/162' is closed, opening it...
> 2018-02-12 20:46:48,982 DEBUG DefaultTcpTransportMapping - Trying to connect
> to 192.168.56.1/162
>
>
> I see that "trying to connect to" is invoked the wakeup, so that must means
> the .select is released, but returns no keys, can there be any reason for
> that?
>
>
>
>
> -Original Message-
> From: Frank Fock [mailto:f...@agentpp.com]
> Sent: Monday, February 12, 2018 8:45 PM
> To: Maayan, Elhanan
> <elhanan.maa...@sbdinc.com<mailto:elhanan.maa...@sbdinc.com>>
> Cc: snmp4j@agentpp.org<mailto:snmp4j@agentpp.org>
> Subject: Re: [SNMP4J] Possible c
Re: [SNMP4J] Java9+ required now?
9 is considered broken because there's a compiler bug https://bugs.openjdk.java.net/browse/JDK-8204322 , in general I believe oracle has killed java with it's 6 months release cycle as they want to monetize it on as much as possible. 9 was never meant for production use, but as a whip to get companies to buy LTS for java 8, (you don't spend years working on something only to kill 6 months after it got out) I always refer to this mail item in Cassandra's list as to the problems commercial companies would be facing. https://lists.apache.org/thread.html/8a24e6b88309601cf36710a6e7bc011ed98b7a2b1f76ac969b86a26e@%3Cdev.cassandra.apache.org%3E This would escalate to other open source projects as developers will attempt to race making the project compatible with coming versions. I mean even today java isn't exactly growing in popularity, but forcing companies to pay oracle's premium prices for it, would drastically change the way management will view it, as they will opt for a accessible products. the only way for java to remain as it is, is if adoptOpenJDK will be strongly and heavily supported, and even that is questionable. -Original Message- From: Fabrice Bacchella Sent: Wednesday, October 03, 2018 10:10 AM To: Maayan, Elhanan Cc: Frank Fock ; Jeremy Norris ; snmp4j@agentpp.org Subject: Re: [SNMP4J] Java9+ required now? *External Message, please be cautious.* > 3. java 9 itself is considered broken, eol, and on top of that migrating to > it , extremely problematic , I suspect many organizations won't go for it due > to those reasons. > Java9 is EOL, migration to it can be difficult, but can also be easy, depending of your code. But I'm not sure we can call it broken. But don't except the situation to improve. J9 was difficult because it introduce many new things that will not go away in latter versions. So if you're afraid to migrate to Java9, you're stuck forever in J8, as the problems will be the same in J11 (the next LTS release). A little like switching from Python 2 to Python 3. ___ SNMP4J mailing list SNMP4J@agentpp.org https://oosnmp.net/mailman/listinfo/snmp4j
Re: [SNMP4J] Java9+ required now?
But snmp4jv3 is still snmp?, we are using a custom binary protocol allready on place with vendors? Get Outlook for Android<https://aka.ms/ghei36> From: Frank Fock Sent: Thursday, October 4, 03:09 Subject: Re: [SNMP4J] Java9+ required now? To: Maayan, Elhanan Cc: Jeremy Norris, snmp4j@agentpp.org *External Message, please be cautious.* Hi, As there is already Java 10 available, we do not need to talk about.Java 9 anymore ;-) DTLS works as expected although the interoperability with OpenSSL DTLS and its NET-SNMP implementation of that was not easy, because NET-SNMP sends some packets in a way the Java DTLS SSLEngine leaves the API user in a state where the SSLEngine documentation lacks information how to continue processing. I figured it out finally, but it was not straight forward. Nevertheless, DTLS works fine. With Java 10, the implementation seems to have improved further regarding error handling and debugging. If you need encryption on UDP, then why not using plain SNMPv3? Its handshake and privacy is much faster and uses much less bandwidth than using (unoptimised) DTLS. With DTLS you should reduce the number of offered algorithms to a minimum on both communication ends to reduce handshake packet sizes. But even then, SNMPv3 is more lightweight. DTLS advantage is using certificate chains. If you do not already have them in place, plain SNMPv3 over UDP would be the better choice. Best regards, Frank On 2. Oct 2018, at 11:11, Maayan, Elhanan mailto:elhanan.maa...@sbdinc.com>> wrote: Hi, I'd like to "hijack" this thread, if it's ok, and ask a few questions about DTLS We have a java app that communicates with device over UDP, with custom binary protocol, and we are considering a few options on how to encrypt them. One of them was DTLS, but this was rejected, because of several reasons. 1. DTLS was only recently inserted into java, so we don't really know how stable it is 2. the java implementation, still leaves you with a lot of "low level" implementation like message ordering, (I'm not sure if this can be handled on any other level with UDP and DTLS) 3. java 9 itself is considered broken, eol, and on top of that migrating to it , extremely problematic , I suspect many organizations won't go for it due to those reasons. How hard was it to integrate DTLS? Have you considered other options? ___ SNMP4J mailing list SNMP4J@agentpp.org https://oosnmp.net/mailman/listinfo/snmp4j
