Hm, no ... same effect ... let me sketch the testing scenario



1.) firing up the master

2.) starting x threads

3.) killing x threads

4.) dumping stack for checking (easy to check: filesize)

5.) repeating 2-4 several times and the filesize is growing 



I also looked inside the stack dump and there are not Exception etc.



Please find attached a stack after several reconnects ...











As far as I understood this approach should reuse the threads. So not spawning new ones when there are still some left - thus I would expect the stack filesize to grow when the maximal number of concurrent slaves increases but stay at the same level when below.



	Ralf



 



On Sep 8, 2013, at 22:08, Sean Luke <[log in to unmask]> wrote:



> On Sep 7, 2013, at 11:31 AM, Ralf Buschermöhle wrote:

> 

>> I just tried the code - but since I am not working on the current SVN branch and I changed some things in the code for my analysis I roughly adapted some things.

>> 

>> Nevertheless I noticed

>> 

>> a.) Connects and Disconnects are fast

>> b.) the threadpool tends to get larger (and larger) ... and the threads are not reused? ... I attached two thread dumps 

>> b.1.) after a few hundred connects and disconnects with (no slave connected then dumping the threads)

> 

> There were some bugs in performing joins.  Try this version.

> 

> <ThreadPool.java>

> 

> Sean