I don’t think it’s memory related - Tomcat is allocated an 8GB heap and according to New Relic it has never used more than 6.5G; there is also lots of PermGen space available.
Cheers, Ian On April 15, 2014 at 4:18:11 PM, André Warnier (a...@ice-sa.com) wrote: Christopher Schultz wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Ian, > > On 4/15/14, 3:33 PM, Ian Long wrote: >> Thanks for the reply. >> >> It looks to me like tomcat just gave up partway through generating >> the request, I’m trying to figure out why. >> >> There are no exceptions in either my application logs or the tomcat >> log itself, which is frustrating. > > Definitely. You checked catalina.out (or wherever stdout goes) as well > as your application's logs? > >> Thanks, I’ll look into the executor. >> >> Apache matches what is set in my connector: >> >> <IfModule prefork.c> StartServers 8 MinSpareServers 5 >> MaxSpareServers 20 ServerLimit 800 MaxClients 800 >> MaxRequestsPerChild 0 </IfModule> >> >> Yes, the connector settings should be fine, there are usually less >> than 20 httpds. > > You mean 20 httpd prefork processes, right? That should be fine: it > means you will need 20 connections available in Tomcat. > >> Forgot to mention that it looks like tomcat returned around 50% of >> what the page should have been, before it hit the Internal Server >> Error. > > Have you run out of memory or anything like that? I was going to ask the same thing, slightly differently. I can think of a scenario which might result in the same kind of symptoms, only I am not sure if it makes sense, Java-wise. A request is recived by httpd, which passes it to Tomcat via mod_jk. Tomcat allocates a thread to handle the request, and this thread starts running the corresponding application (webapp). The webapp starts processing the request, produces some output, and then for some reason to be determined, it suddenly runs out of memory, and the thread running the application dies. Because Tomcat has temporarily run out of memory, there is no way for the application to write anything to the logs, because this would require allocating some additional memory to do so, and there isn't any available. So Tomcat just catches (a posteriori) the fact that the thread died, returning an error 500 to mod_jk and httpd. As soon as the offending thread dies, some memory is freed, and Tomcat appears to work normally again, including other requests to that same application, because those other requests do not cause the same "spike" in memory usage. Tomcat/Java experts : Could something like this happen, and would it match the symptoms as described by Ian ? And Ian, could it be that some requests to that application, because maybe of a parameter that is different from the other cases, could cause such a spike in memory requirements ? --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
