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 <[email protected]> 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 > >>> [email protected] > >>> 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 > [email protected] > http://lists.agentpp.org/mailman/listinfo/snmp4j > _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
