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