I'm trying to figure out how Derby's network server manages threads, maybe someone with knowledge of that area can help.
I have a client-side connection pool with a minimum of 10 connections, maximum of 100, and idle timeout of 300 seconds. Using JMX, I can see that the pool is indeed sitting at 10 connections. However, when I perform a thread dump on the server-side, I see that there are dozens of threads waiting on socket read() like this one: DRDAConnThread_19380 java.net.SocketInputStream.socketRead0(Native Method) java.net.SocketInputStream.read(SocketInputStream.java:150) java.net.SocketInputStream.read(SocketInputStream.java:121) org.apache.derby.impl.drda.DDMReader.fill(Unknown Source) org.apache.derby.impl.drda.DDMReader.ensureALayerDataInBuffer(Unknown Source) org.apache.derby.impl.drda.DDMReader.readDssHeader(Unknown Source) org.apache.derby.impl.drda.DRDAConnThread.processCommands(Unknown Source) org.apache.derby.impl.drda.DRDAConnThread.run(Unknown Source) Full dump of "DRDAConnThread" theads here: http://dpaste.com/1032074/ I do not understand why Derby is keeping these around once the client-side has closed the connection. What controls server-side connection (thread) retirement? If it is pooling them for efficiency, it still seems there must be a way to control how many/how long they live. Looking at the thread dump, something else interesting is that DRDAConnThread_0 thru 9 seemed to die off correctly. DRDAConnThread_10 thru 19 are still around. And then there is a jump in number to threads numbers > ~19300. Thanks in advance. Brett
