Michael wrote:
I was thinking more of user code debugging. I hope tomcat is not hungingI know what JMX itself is--I'm going by the check-in comment:the debugging feature (JMX support) you're adding.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.
I want to add JMX support and make calls to store the
"state" of the thread, i.e. what is the thread doing.
This would allow people to debug hunged threads and
allow more control.
Perhaps I misunderstood this to mean debugging of the TC code, rather than the servlet's.
too much :-) It looks like a nice feature - like the status page in apache ( that shows you all requests that are active ).
In any case, ThreadPool will at least need this patch, since removeThread() is never called. I also can't imagine why addThread() and removeThread() would need to be more than "private", given their role. Other liberal access modifiers abound.
I'll apply your patch, thanks. You're probably right that addThread() doesn't need to be public - but I don't think it hurts too much either.
Also: MonitorRunnable, now that it has a start() method (for JMX, I presume) has no restriction on running more than one thread. This undercuts the meaning of "interval", and makes stop() poorly defined.
IMO MonitorRunnable, the session expiration thread ( one per ctx ) and the reloading thread ( one per ctx again ) should all go away and be replaced by a single mechanism. Maybe the JMX timer ? I took a look at GenericObjectPool and all associated classes - and it feels far too complex for my taste. If you send a patch to make the whole thread pool pluggable - I'm ok and that would allow you to use whatever pool you want. My requirements: the TP must be an mbean and it must use an interface that allows passing the handback object. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
