[SNMP4J] Protocol mismatch (or socket errors in general) leadto many connection attempts using snmp4j 1.10.2

[bangarappa]

Hi Frank,

What are the processing changes are done as part of this. I am hitting the
similar case of failure when the event size is very huge.

Thanks,
Bangar

On Sun, Feb 14, 2010 at 9:01 PM, Frank Fock <fock at agentpp.com> wrote:

> Hi Warren,
>
> I think I have fixed now the problem you reported.
> Please try out the current snapshot at:
> https://server.oosnmp.net/dist/snapshot/org/snmp4j/snmp4j/1.11-SNAPSHOT/
>
> Best regards,
> Frank
>
> On 30.12.2009 14:14, Warren Cooper wrote:
> > (Resending to include the mailing list in case you missed my followup
> > questions. Thanks)
> >
> >  >...Any suggestions are welcome...
> > How about if the the queued entries obey the retry configuration
> > setting? i.e. if the retry count is set to 1, then a message in the
> > pending list will only register for OP_CONNECT one more time. After that
> > it is simply discarded from the pending list.
> >
> > I am seeing cases where the socket entry is null in connectChannel( )
> > because the socket channel fails this check:
> > --> if (sc.equals(entry.getSocket().getChannel())) { <--
> > So no event is fired and that warning message
> > --> logger.warn("Message not found on finish connection"); <--
> > is sent instead. Once a few messages are queued into the pending member
> > and the server socket connection is down, this really churns cpu
> > streaming an endless amount of these 'Message not found...' messages and
> > eats memory quickly if the traps include variables w/ alot of data.
> >
> > I'm investigating overriding the DefaultTcpTransportMapping class, but I
> > just wanted to make certain you understood the potential impact of the
> > problem I am reporting.
> > -thanks
> >
> > Frank Fock wrote:
> >> Warren,
> >>
> >> You can (and should) handle such a situation in your code
> >> by implementing a TransportStateListener and add it
> >> to your TcpTransportMapping.
> >>
> >> I have no idea how this could be solved in a generic
> >> way without a negative impact on existing code.
> >> Any suggestions are welcome.
> >>
> >> Regards,
> >> Frank
> >>
> >> On 28.12.2009 15:57, Warren Cooper wrote:
> >>> If there is a connection problem between an SNMP agent configured to
> >>> send TCP in its attempt to send events to an SNMP server, and there is
> >>> a problem making a connection, many attempts to send the events will
> >>> fail. ( It's a problem because the pending list (member in
> >>> DefaultTCPTransportMapping) will continue to grow.
> >>>
> >>> To see the problem, configure an SNMP client to send 40 events over TCP
> >>> to a SNMP server expecting UDP.
> >>> (But this problem would happen in any case where if
> >>> (entry.getSocket().isConnected()) ) check in processPending() is not
> >>> true.
> >>> As you know, this is a serious problem since CPU resources are impacted
> >>> and memory could eventually be exhausted if the problem continues for
> >>> over an extended period of time and enough events are written to the
> >>> 'pending' list object instance.
> >>>
> >>> thanks
> >>> _______________________________________________
> >>> SNMP4J mailing list
> >>> SNMP4J at agentpp.org
> >>> http://lists.agentpp.org/mailman/listinfo/snmp4j
> >>
> >
>
> --
> AGENT++
> http://www.agentpp.com
> http://www.snmp4j.com
> http://www.mibexplorer.com
> http://www.mibdesigner.com
>
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j
>