Leo Sutic wrote:
>
> All,
>
> the Excalibur component manager has a severe fault: It is not possible to
> choose the size of the component pools. (Nor is it possible to subclass the
> PoolableComponentHandler in a neat way as the m_pool member is private and
> thus not accessible for subclasses.)
>
> This means that in a heavily multithreaded environment (40+ threads), the
> pool will (almost) always try to create new component instances, degrading
> performance and leading to:
Ok. I personally haven't been able to push it to the point of breaking.
Obviously you have.
> The solution I see is:
>
> Include "hints" in the Configuration object sent to the component
> manager/handler. For example, we could let the attributes
> excalibur:poolMaxSize, and excalibur:poolMinSize specify the maximum and
> minimum sizes of the pool. The default values would be as in the
> AbstractPool (the current defaults). The advantages are:
> + Unchanged (Java) interface to the component manager, preserving binary
> compatibility.
The ComponentManager interface should be considered immutable--so that is
good.
> + Easily configurable pool parameters.
Ok.
> Disadvantages:
> - Creates some "magic attributes".
Maybe so, but fine grained control of pools is important. The SAXConfigurationHandler
ignores namespaces, so we are going to have to use simple attributes.
> - Changes interface of DefaultComponentPool, PoolableComponentHandler
This is not a problem--the change may have been prepared for, but not
ever used.
> So I'd like to call for a vote on this. Should the ExcaliburComponentManager
> and related classes be changed to accept these attributes in the
> Configuration object passed to the addComponent method?
Yes. +1
> I also keep getting these, and I am certain that I'm *not* trying to release
> a component that I have not obtained through the same component manager:
Hmm. What kind of machine do you have? On my machine, and on Santiago's
machine, we haven't every gotten these. My machine is a single Athlon,
and Santiago has a dual P-II 400 system. It could be that your machine
simply stresses it more--so that we have uncovered a weak spot.
Could you give a quick run down of hardware/JVM/OS that you are using?
By hardware I mean number of CPUs, CPU speed, CPU brand, physical memmory.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
