> From: "Chris" <[EMAIL PROTECTED]> > Sent: Monday, May 16, 2005 12:32 PM
> Sorry if this is a dupe, but as far as I can tell, it didn't go through. > > Setup: > Tomcat 5.0.28 > JDK 1.4.2_06 > W2K > > Currently, we are running a rather large applet served from TC. When > the first user logs on, TC memory usage jumps up about 60MB. When > another user logs on after the first one is finished, the memory doesn't > really change. Also, the cpu spikes pretty heavily, but only for about > 10-20 seconds. The problem that occurs, is that if multiple people log > on at the same time, the memory spikes for 60MB for each concurrent log on. Sounds like a caching issue on Tomcats end, but I don't know for sure. > 1. Would using ZIP compression help alleviate the problem? The cpu > doesn't seem to be as much of a limiting as the memory. I would think > that the compression would help users log in faster, thereby helping > reduce the chances of concurrent log ons. No, it wouldn't help. First, Applets are just Jar files anyway, and those are normally already compressed, and second, if Tomcat is indeed for whatever reason loading the entire applet into memory before streaming it, then it would do the same thing before compressing it, so it wouldn't help there either. > 2. Is there a way to queue connections so that tomcat will wait until > it has available memory, thus preventing the OutOfMemory error? AFAIK, > once TC gets an OOM error, it won't do anything until it's restarted. You can write a Filter that counts how many folks are requesting the resource, and if more than a certain number are accessing it, you can wait() until the queue frees up space, but you have to write all of this yourself. > 3. Would upgrading to TC 5.5.x and/or JDK 1.5 help any? Dunno about that. What I would do is set up the request logging (via the Valve in server.xml), and see what kind of requests you are getting to your Applet URLs. If they are simple "GETs" for the whole shebang, then you can easily make the URL a custom Servlet instead, and it can more sanely read the Applet from disk and send the data incrementally. You may need to make sure that the OutputStream that you are using the THE stream to the client, and not a buffered stream by Tomcat. Tomcat at times will buffer output so that it can set the Content-Length properly in the header. This is mostly for dynamic content, but you should be able to get access to the correct stream, or turn off the buffering. I'm actually surprised the Tomcat would cache the static resource, which is what it SEEMS to be doing, but I don't know why it would be doing that. Regards, Will Hartung ([EMAIL PROTECTED]) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
