db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Wooldridge <brett.wooldri...@gmail.com>
Subject Connection threads sticking around
Date Sat, 23 Mar 2013 07:18:51 GMT
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:

java.net.SocketInputStream.socketRead0(Native Method)
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:


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.


View raw message