> This change was already committed. Please consult the CVS.
The only change I'm noticing with respect to a thread configuration is this:
Old: <max-threads>40</max-threads>
New: <max-threads>100</max-threads>
As I understand it, in the old code, all threads were available for any
service that needed any thread. In the new code, the default pool is
available, but the connection manager can be told to limit its use:
<connections>
<idle-timeout>300000</idle-timeout>
<max-connections>30</max-connections>
</connections>
The default is 30 connections, so 60 threads, leaving 40 for everything
else.
One thing I'm seeing is that the Excalibur ThreadPool code is broken as far
as I can read. The chain of events is this:
ThreadManager reads max value from XML
Threadmanager passes max value to DefaultThreadPool
DefaultThreadPool creates SoftResourceLimitingPool, passing max as MIN
SoftResourceLimitingPool uses 2*min as the new max value
The new code is able to use per service thread pools, and perhaps Peter
should implement that change in the configuration. That way we can tune
each service by telling it which thread pool to use. If we don't want a
dedicated pool, we just allow that service to use the default. If a service
is configured to use a specific pool, and told that it is dedicated, it can
do further optimization.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
