Yeah...I wasn't suggesting that for a hosted environment with hog detections anyway, though. What I was trying to do was point out the limitations I'm aware of with standard APIs that are available. The current limitation I'm aware of is that you can see when memory's getting tight, but you cannot see why (this is, of course, not including the JNI options mentioned here), so the best you can do is to politely ask components to release memory or you can just throw the baby out with the bathwater by undeploying all loaded components and then redeploying them. My original intent was not to suggest we take that route, but to instead show that the idea of a memory monitor wasn't really feasible to begin with.
I'm now recognizing the poor communication of that idea on my behalf by not starting off with "I don't think it'll work" and instead commenting on what worked for me in an environment far removed from the one in question. -----Original Message----- From: marc fleury [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 11, 2002 1:53 PM To: Jboss-Development@Lists. Sourceforge. Net Subject: FW: [JBoss-dev] Implementing a Resource Protection System? Dain helps me say it nicely, Marcf > -----Original Message----- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > Sent: Thursday, July 11, 2002 12:29 PM > To: marc fleury > Subject: Re: [JBoss-dev] Implementing a Resource Protection System? > > > Here is a more friendly response: > > This is a bad idea. You are saying that in the hosted > environment, when > one module is a hog, the system asks "politely" for the other well > behaved parts, to "please let go of some memory, cause the hog over > there wants some." More importantly you are talking about a > huge amount > of effort when you can simply run multiple JBoss instances. If you > compare the cost of say an extra 20 megs of memory per JBoss > instance to > the cost of developing and maintaining this code, you will > agree with me > and buy an extra 256 MB chip for $50. > > -dain > > marc fleury wrote: > > Dain, > > > > How can I say this nicely to you? > > > > marcf > > > > > >>-----Original Message----- > >>From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > >>Sent: Thursday, July 11, 2002 12:22 PM > >>To: marc fleury > >>Subject: Re: [JBoss-dev] Implementing a Resource Protection System? > >> > >> > >>I thought we were not going to call people (or their ideas) dumb > >>anymore. I agree that is is a dumb idea, but we should be nicer. > >> > >>-dain > >> > >>marc fleury wrote: > >> > >>>>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. > >>> > >>> > >>>Rhet, > >>> > >>>LOL, do you realize how dumb this is??? You are saying that in the > >>>hosted environment, when one module is a hog, the system asks > >>>"politely" for the other well behaved parts, to "please let > >> > >>go of some > >> > >>>memory, cause the hog over there wants some"... Dude, you were > >>>sleeping when you wrote this. I'll sue you if you commit > >> > >>this to our > >> > >>>tree :) > >>> > >>>Marcf > >>> > >>>PS: for your own application it was probably fine > >>> > >>> > >>> > >>>------------------------------------------------------- > >>>This sf.net email is sponsored by:ThinkGeek > >>>PC Mods, Computing goodies, cases & more http://thinkgeek.com/sf > >>>_______________________________________________ > >>>Jboss-development mailing list > >>>[EMAIL PROTECTED] > >>>https://lists.sourceforge.net/lists/listinfo/jboss-development > >> > > > -- > xxxxxxxxxxxxxxxxxxxxxxxx > Dain Sundstrom > Chief Architect JBossCMP > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek PC Mods, Computing goodies, cases & more 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 PC Mods, Computing goodies, cases & more http://thinkgeek.com/sf _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
