james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Peters patch doesn't actually work...
Date Sun, 13 Oct 2002 22:27:01 GMT
> 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:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message