Michael wrote:
-1 for the change to commons-pool. Sorry, but this will add some overhead. And quite frankly, we do not need the flexibility.Costin Manolache wrote:The usual: code that's also used and tested by other projects; code that more people are familiar with; not further reinventing code.Can you list any benefits on doing that ?
More-flexible idle object cleanup; a timeout option on blocking when the pool is exhausted. (Can't say whether you've been missing these.)Any missing feature we'll gain ?
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.
The JMX feature is a monitoring feature, not a debugging feature.
Remy
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
