I've thought about doing this in some of the other architectures I've written from time to time. It's possible to keep an eye on memory usage and track its stats over time, so you can know when memory's becoming scarce and start telling different parts of the system "Memory's tight. Can you do what you can do to lighten the load?" That wasn't all that hard to do- every time this architecture deployed a "job" to run, it kept a handle to them and would asynchronously call a method on them that contained "best effort" code to lighten up the load and call the GC. That works fine when you just know that you're using more and more memory and just want to politely ask deployed code to attempt to help out.
The real issue with what you're asking is, though, that I don't know that there is a way to, within a Java runtime, break down memory usage at a fine-grained level to spot a memory hog. One possible tack to take would be to make each classloader keep tabs on how many times it gets requests for object creation, but even that doesn't get you what's needed, because I'm not aware of a mechanism in place to actually chart how much memory is getting consumed by the classes instantiated out of that classloader. As far as I see, the API does not support this. The memory reporting methods are for the entire JVM, and breaking down that aggregate information by subsystem in the JVM would be tricky, if not downright impossible. -----Original Message----- From: Hunter Hillegas [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 10, 2002 4:12 PM To: JBoss Dev Subject: [JBoss-dev] Implementing a Resource Protection System? How hard would it be to implement some kind of resource protection system for deployed JBoss apps? I'm thinking mainly memory... Not allowing an app to continue to grab memory until the container dies, instead, shutting down that app and sending notification to an admin... Could be useful for a hosting environment... Possible? Cheers, Hunter ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Two, two, TWO treats in one. http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
