Hi,
I just fixed the unit tests so that each test (we have 47 now) cleans up
after itself. Some were getting left running and the house keeper and
prototyper threads were left running. This got me thinking about how
Proxool would scale up when using many pools.
The old way (at 0.7) had at least two threads per pool and some JDKs
(1.4.0_01 on Linux for instance) don't cope well with 30 odd threads. At
least, things start to get slow.
So I've just finished a painstaking rewrite of the house keeper and
prototyper code. There is now just one house keeper that looks at all
the pools. And one prototyper too.
A useful imapct of this rewrite was to simplify a lot of things. I
created a handful of new classes but at the same time reduced the
complexity of the ConnectionPool class (which is still over 750 lines
long).
At the moment it is hard coded to just one thread for house keeping and
prototyping, but it would be easy to increase that. I wonder how we
should decide how many threads to have?
We could use a formula. Like, one house keeper for every five pools. And
have it so you could override that in the config.
Or we could do some measurements. Work out how much idle time the
threads have and only start a new thread if the existing threads aren't
coping.
Cheers,
--
Bill Horsman
Proxool
http://proxool.sourceforge.net
ICQ: 119577180
|