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]
