[SNMP4J] Exception in thread "DefaultTCPTransportMapping": java.lang.ArrayIndexOutOfBoundsException

Frank Fock fock at agentpp.com
Thu Jan 6 11:23:43 CET 2011


Hello Rui,

The fireConnectionStateChanged is indeed not
thread safe against concurrent listener
add/remove operations.

Making it thread safe could have a performance
impact - that's why it had not been done yet.

To work around the issue you can use a single
listener which handles the 1500 agents (listeners)
internally and thread safe.

Meanwhile, I will try to improve the
fireConnectionStateChanged method to be fast
and thread safe.

Best regards,
Frank

On 06.01.2011 10:24, Rodrigues, Rui 1. (NSN - PT/Amadora) wrote:
> Hello,
>
> I'm using SNMP4J 1.11.1 in my application and the following error
> happens several times:
> DefaultTCPTransportMapping_10.50.51.195/0 ERROR (#28@) [STDERR]
> Exception in thread "DefaultTCPTransportMapping_10.50.51.195/0"
> DefaultTCPTransportMapping_10.50.51.195/0 ERROR (#28@) [STDERR]
> java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 93
> DefaultTCPTransportMapping_10.50.51.195/0 ERROR (#28@) [STDERR]
> at java.util.Vector.get(Unknown Source)
> DefaultTCPTransportMapping_10.50.51.195/0 ERROR (#28@) [STDERR]
> at
> org.snmp4j.transport.TcpTransportMapping.fireConnectionStateChanged(TcpT
> ransportMapping.java:132)
> DefaultTCPTransportMapping_10.50.51.195/0 ERROR (#28@) [STDERR]
> at
> com.nsn.genmed.common.snmp.CustomTcpTransportMapping.access$1300(CustomT
> cpTransportMapping.java:45)
> DefaultTCPTransportMapping_10.50.51.195/0 ERROR (#28@) [STDERR]
> at
> com.nsn.genmed.common.snmp.CustomTcpTransportMapping$ServerThread.connec
> tChannel(CustomTcpTransportMapping.java:838)
> DefaultTCPTransportMapping_10.50.51.195/0 ERROR (#28@) [STDERR]
> at
> com.nsn.genmed.common.snmp.CustomTcpTransportMapping$ServerThread.run(Cu
> stomTcpTransportMapping.java:749)
> DefaultTCPTransportMapping_10.50.51.195/0 ERROR (#28@) [STDERR]
> at java.lang.Thread.run(Unknown Source)
>
> The application uses a single MultiThreadedMessageDispatcher (with 20
> threads) and a single Snmp instance with this
> MultiThreadedMessageDispatcher. A CustomTcpTransportMapping is used and
> the code is identical to the DefaultTcpTransportMapping (we just added a
> method to get some info abiut the sockets list).
>
> The application handles 1500 connections to agents and there can have
> connect and disconnect at the same for different agents. Each class
> representing an agent implements TransportStateListener and is
> registered in the TcpTransportMapping (so one can have 1500 listeners).
>
> Looking at the code of
> org.snmp4j.transport.TcpTransportMapping.fireConnectionStateChanged(Tran
> sportStateEvent), I see that the code may not be thread safe... When
> getting the listeners vector size, count can be equal to X listeners but
> during the itereation, listeners may have been registered or
> unregistered. And I think in my case, some listeners have been
> unregistered meanwhile and ArrayIndexOutOfBoundsException is thrown.
>
> if (transportStateListeners != null) {
>        Vector listeners = transportStateListeners;
>        int count = listeners.size();
>        for (int i = 0; i<  count; i++) {
>          ((TransportStateListener)
>           listeners.get(i)).connectionStateChanged(change);
>        }
>      }
>
>
> Then the critical problem is that the exception is not catched anywhere
> so the CustomTcpTransportMapping.ServerThread dies and all TCP
> connections are lost and the application needs to be restarted.
>
> I checked SNMP4J 11.1.2 and I don't see any fix for this.
>
> Can you comment on this?
> Thanks
>
> One note: the application runs in a powerfull machine (with more than 30
> CPUs/Cores) so we have a lot of multithreading/multiprocessing.
>
> Best regards,
> Rui Rodrigues
> _______________________________________________
> 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




More information about the SNMP4J mailing list