Hi Yoav, > You have the two calls in the Runtime class (totalMemory() and > freeMemory()), and that's pretty much it. This of course reflects only > the heap. So you can have a background thread that checks freeMemory() > every so often and if the free percentage falls below a certain > configured threshold, sets some global flag variable that servlets (or > better yet a simple filter) consults when deciding whether to allow > servlet requests.
yup that was what I though of doing. I was surprised, though, that the JVM didn't try to increase the totalMemory for this app, though, as it looked like it could have. > >free Memory = 172544, totalMemory = 6.6650112E7, maxMemory = > >1.34217728E8 > > How were the above obtained? I added a log4j message in the servlet code to report this whenever tuples are inserted by a user via our API. These were the last measurements before the OutOfMemoryError. Just before the crash, I could see freeMemory fluctuating around, and I guess at some point, it must have dipped below some threshold. I'm just now looking at the standard tomcat4 script in /etc/init.d to figure out whether any -Xmx parameters were set, but I guess the jvm thinks maxMemory is 134MB, looking at the numbers above. > This is a fragile situation with or without the above solution. > Benchmark your system to know how many max concurrent requests you can > support given your hardware, and make sure your customers/users know > this number. > You may also want to consider a script to monitor your log for > OutOfMemoryError messages and restart tomcat or notify admins in this > event. good ideas, thanks for the suggestions. cheers, Andy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
