Everybody heathy? If you operate a 24*7 production plant with a server like JBoss, you shurely care about the "health" of your server. Now in theory this is nearly trivial: we have JMX and friends. Any kind of monitoring can be done with it, but do we do? Of course a lot of aspects are application specific, and for the rest of it you may like to pull myserver:8080/jmx-console.
I still have some - trivial - thoughts about what could be done on the server side to faciliate things; and I post my thoughts here to collect some of your opinions on this (you care about health, do you?). 1) Threadcount For me this is more or less a linux problem, allthough I found questionable things even on NT4. The problem is that the current thread count reported by the JVM is garbage. The best thing i can think of is traversing the threaddump and counting threads on the fly. 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. 3) Memory usage I don't understand much of the JVM heap structure but I know of tools (e.g. JProbe) which which can provide you with information about each and every living object on the heap. These tools do at least use the JVM debugging API, I don't know if they need modified native classes to do so. If you do know, please let me know. 4) History The current JBoss measures for counting threads and memory usage don't keep a history about thread usage in the past. With a monitoring tool online all the time we could solve the problem on the client side. It should be trivial to support this through a collection MBean on the server side. The interesting part comes with the persitence of this information? What to do after some crash (out of memory)? Perhaps log4j is the solution? Or do you favor database storage? (Even that could be done with log4j and appropriate Logger/Appender setup. 5) Caches, pools and such I would prefer more control on caches, pools and containers. If everything is "done right" (with SoftReferences?) we should not fear out of memory due to bad configuration. But as I noticed on this list these aspects are on the TODO for Matrix2 anyway. Ok, just me 2c, curious about what you think, Michael Bartmann ------------------------------------------------------- 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
