Remy Maucherat wrote: > BTW, can't Linux 2.5/2.6 handle thousands of threads without any problem > ? I remember reading an iterview of Ingo who said JVM performance and > thread handling should be way better in 2.6. > The idea is that there's nothing wrong with designing with threads in > mind (I think that's good design), but the problem is that it doesn't > quite work too well with most current OSes.
I'm pretty sure most OSes and apps will have problems with thousands of threads ( especially if a many are in RUN state ). They did a lot of changes in the linux scheduler - so hopefully thread handling improved too. I'm not very sure "normal" one request/thread will scale well for 1000s of concurent requests. That's an area where NIO would help ( select ). Squid ( and few other servers ) uses a single thread plus select plus some tricks to deal with extremely high load. >> I agree. We could pretty easily provide JMX-based operations for >> everything that manager does (so that they're accessible from a JMX-based >> client), and have the manager webapp itself just be wrappers around those >> same MBean operations (for easy integration into non-JMX clients that can >> perform HTTP requests). > > I added (theorical) support for MC4J in 5.0 some time ago, BTW. The only > problem is that there's a version clash with MX4J (Tomcat has to use an > API which changed between MX4J 1.1 and 1.1.1 to start the JRMP > connector, and MC4J only works with MX4J 1.1 at the moment). > After hacking to get it to work, in order to test the feature, I noticed > the start/stop/reload operations weren't declared on the model MBeans. I added a reload for Context in the model mbean some time ago, and it seemed to work. For "remote" jmx - yes, MX4J RMI should work ( I was able to use it ), but it's very tricky. I think adding some simple operations in the ManagerServlet would be a good idea - just a get/set for a single attribute and a simple no-param method invocation would cover a lot of use cases. And we can easily implement an JMX-over-http on top of this. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
