avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <pro...@apache.org>
Subject Re: [event] TPCThreadManager running out of threads
Date Fri, 24 May 2002 17:47:31 GMT
On Friday 24 May 2002 01:35 pm, Berin Loritsch wrote:
> Sounds good.  Remember, that we don't want too many lifecycle
> methods on the ThreadManager.  We either use a Context or Parameters.

TPCThreadManager now has LogEnabled, Parameterizable, Initializable and 
Disposable. (I opted for Init/Dispose rather than Startable, since the 
contained ThreadPool is Disposable).

> Now the ContextManager in Fortress can pass in a reference to the
> Context it's building....

Thats a very good argument for using Context vs Parameters, especially since 
ContainerConstants also define some of the values needed.

> Which is easier to deal with?  I would rather deal with the Context
> because of the Fortress integration.  The DefaultContext object is
> not difficult to use, and it is more flexible as we can store
> arbitrary objects in it.

The benefit from using Parameters, is the ease of supplying defaults for 
values that aren't there, vs catching a ContextException. Parameter also has 
handy type-safe methods to get an int/long.

> If I am not mistaken, CommandManager will default to using the
> TPCThreadManager if no other ThreadManager is passed in the
> constructor.

CommandManager has a parameter-less constructor, so unless I'm missing 
something the auto-created CommandManager never gets attached to a 

> In essense, that default would mean a unique ThreadManager
> per CommandManager...

If you use nested Container's child containers would use a parent's 
CommandQueue though... so you won't end up with too many.

> I like providing reasonable defaults--which is why I added the
> SystemUtil stuff.  I figured it was easier to determine the
> number of processors automatically than force the user to come
> up with the value.

Agreed :)


peter royal -> proyal@apache.org

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message