David Jencks wrote: > <snip> > >>>2) Thread usage >>>If you are not an expert on every single part of JBoss, it might be >>>a detectives work to find out where all those nice threads in the >>>threaddump come from. >>>This is even more criticall, as we migrate to centrally managed thread >>>pools, where its more easy to do it wrong (not naming them >> >>appropriate). >> >>>Thread creation (and even pooling) doesn't come at no cost. I think >>>it might be affordable to do some more bookkeeping (factory?) >>>about how and when and from which part of the system (stacktrace?) >>>threads get allocated. This information - if accessible via JMX - >> >>should >> >>>give you a warm feeling. >> >>I agree. This is why I want a centrally managed thread factory (pool). > > > In jboss 4 there is an mbean that provides the jca 1.5-mandated kind of > thread pool (org.jboss.resource.work.BaseWorkManager) that uses the > concurrent package PooledExecutor. I think it may be more useful to have a > universally used mbean for thread pools than one big thread pool so you can > set them up for different purposes. I'd like to either use this mbean as > our standard thread pool or know what its limitations are. Anyone have a > suggestion of a good place to try out using it inside jboss?
This is exactly what I was thinking. Whether it is a partitioned pool, many mbeans, or a just a thread factory (not a pool) doesn't really matter to me. As for a good place to try it out, you could look at the trunk nio invoker or JCA. It would be cool to have Tomcat and Jetty delegate to our thread pool, but I don't think that is likely any time soon. -dain ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
