Michael wrote: > Costin Manolache wrote: > >>Can you list any benefits on doing that ? >> > The usual: code that's also used and tested by other projects; code that > more people are familiar with; not further reinventing code.
What projects are using commons-pool ? And how more testing are we talking about ? How big is the community that is familiar with the code ? TP has been around for at least 3 years, and has been used in most tomcat releases, in quite a few production sites. The main reason I'm cautious - this is a very critical piece of code. I would consider making the implementation of the TP pluggable, that would require few small changes and a hook. It depends on finishing the hooks and plugins proposals - but we should have that soon. A pluggable TP would allow the naive no-TP solution for small footprint, integrating with other products TP, or any other similar concept. However the default we ship will most likely remain TP, at least until we have a clearly better solution. I would also vote +1 on moving the TP to jakarta-commons, so other projects can use it. ( there is no rule against having 2 implementations of something ). >>Any missing feature we'll gain ? >> > More-flexible idle object cleanup; a timeout option on blocking when the > pool is exhausted. (Can't say whether you've been missing these.) > >>ThreadPool seems to work fine. >> > Two days ago, I thought the code was sketchy. Now that I look closely at > the version diffs, I see that the code that I considered most sketchy > was just committed in 1.5. I have no specific bug to point to, thus my > original question--I want to know what the more experienced maintainers > think of ThreadPool. It appears that you thought that there were > problems surrounding the code, judging from the debugging feature (JMX > support) you're adding. And Remy thought about refactoring it a few > weeks ago. JMX is not a debugging feature - it's monitoring/control. It would allow people to see how many threads are used, to eventually stop threads or change the parameters dynamically. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
