On 23.03.2013 17:18, Brett Wooldridge wrote: > 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. >
I think Derby has its own cache of connection threads so save creating new ones, cf NetworkServerControlImpl#freeThreads (http://svn.apache.org/viewvc/db/derby/code/branches/10.9/java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java?view=markup line 316). The maximum number is controlled by derby.drda.maxThreads (http://db.apache.org/derby/docs/10.9/adminguide/radmindrdamaxthreads.html). See also the property controlling the minimum number of threads at startup (http://db.apache.org/derby/docs/10.9/adminguide/radmindrdaminthreads.html). I don't think there is a mechanism to withdraw threads from that pool if they sit idle for a long time though. Thanks, Dag > 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 >
