Normal Call Stack for an Idle Toolbox Connection

By default, all connections opened that use the classes provided in the IBM Toolbox for Java create a thread to handle communications to and from IBM i. This thread remains active until the connection is closed. When you investigate a thread dump of an application that uses toolbox connections (including JDBC), it is normal to see threads in the following state:

NAME: "AS400 Read Daemon-xx"

STACK:

at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(Unknown Source)
at com.ibm.as400.access.DataStream.readFromStream(DataStream.java:48)
at com.ibm.as400.access.ClientAccessDataStream.construct(ClientAccessDataStream.java:46)
at com.ibm.as400.access.AS400ThreadedServer.run(AS400ThreadedServer.java:321)
at java.lang.Thread.run(Unknown Source)

This stack is the normal call stack of an idle toolbox connection, and it does not signify that a problem is occurring within the toolbox. The count of the number of threads of this type provides the number of connections that are currently open by the toolbox classes in the application. In contrast, when a toolbox connection is waiting for a reply from the server, a call stack similar to the following is observed in the thread dump:

NAME: Varies because it is an application thread.

STACK:

at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at com.ibm.as400.access.AS400ThreadedServer.receive(AS400ThreadedServer.java:303)
at com.ibm.as400.access.AS400ThreadedServer.sendAndReceive(AS400ThreadedServer.java:419)
<MORE>

A common complaint is that an application is hung, and many threads contain the idle toolbox connection stack. However, if none of the threads indicate that the application is waiting for information to be returned (AS400ThreadedServer.sendAndReceive), the idle stacks are not the problem. This condition usually indicates application has "leaked" toolbox connections. Connections are opened or checked out from a connection pool and were not closed or returned to the pool. If so, then the application needs to be investigated to determine where connection leaks are occurring.