Upon investigation and reading http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=2669
Perhaps I need to deregister my database driver. I thought the database driver would be released when i explicitly close the statement and connection. I do not fully understand why I would need a separate listener to deregister my driver, shouldn't I be able to do this inside my servlet? I guess DB pooling would fix this issue, but I should know how to do it in my java code. thanks On Wed, Jul 15, 2009 at 9:35 AM, Lucas Vickers <lucasvick...@gmail.com>wrote: > Grepping all my java code for "System.exit" returns blank. This is not > surprising as I am the only user on this box. > > I went and changed the shutdown keyword in server.xml (won't make a > difference, and didn't make a difference) > > The unknown shutdown only occurs when I am doing database access. So far I > have only tested it on an update query, not a simple select query. I stress > tested the same setup with a simple HelloWorld servlet and it ran without > issue. > The database setup is as follows: > > Java: 1.6.0_14-b08 > Tomcat: 5.5.25 > OS: Linux 2.6.18-028stab060.8 > MySql: 5.0.81 > > I do not have database pooling. I have tried both these drivers: > - com.mysql.jdbc.Driver > - org.gjt.mm.mysql.Driver > > Currently I am using: com.mysql.jdbc.Driver > > > I have added > -Xloggc:../logs/java_gc.out > -verbose:gc > > and successfully caused my server to restart after 2 minutes. > > The java GC logs are attached. The memory usage appears to increase but > not anything insane. > I am running on a dedicated virtual host, I have 512 dedicated ram and can > burst to 1gig. > > I've attached 3 java crash logs (.crash1.txt - .crash3.txt). They all > appear to crash around the time when memory hits 200-250 MB > My server java memory args are: > -Xms384M -Xmx1024M > So I do not get where 250 would come into play. > > For kicks I stress tested the helloworld app again using the GC logging and > it never gets above 70 megs, so obviously the database connectivity is > causing issues. > > Perhaps DB pooling is worth my time, but I do not think it would help the > original issue I was trying to solve. I started stress testing this server > because it was restarting after 10 min doing a demo that requires > connections once every 2 seconds. For kicks I decided to replicate this. I > took my stress test app (which is just a loop that HTTP POST 's data to be > written to the db) and put a 2 second pause in there. The setup is not > identical to what was causing issues before (I have removed geoserver to > determine if that was causing the issue), but the result is the same. I ran > 2 test clients in a loop (delay every 2 seconds, so it's about a db update > once a second) and it took longer but I was able to get tomcat to restart. > The log for this instance is (java_gc_out.slow_crash.txt). This crash > occurred when we hit around 200megs of memory. > If I had to guess I am leaving open database connections or leaking db > memory, but upon reviewing my code I do not see how this could be. I've > attached the simple servlet for reference. I am not using database pooling > in the servlet and the database definitions in web.xml and context.xml have > been commented out. > > With such a simple task as a db update every 1-2 seconds, why is the memory > continually increasing? > > What else should I be looking into? I suppose I should monitor how many > threads are created. > Again I grepped the logs and tomcat puts out no WARN or ERROR information, > only an INFO statement that it's pausing cayote. > > Thanks guys > Lucas > > > > > On Mon, Jul 13, 2009 at 4:49 PM, János Löbb <janos.l...@yale.edu> wrote: > >> >> On Jul 13, 2009, at 3:47 PM, Caldarale, Charles R wrote: >> >> From: Lucas Vickers [mailto:lucasvick...@gmail.com] >>>> Subject: Logging of memory / thread activity >>>> >>>> I have an issue where Tomcat shuts down without reason. >>>> >>> >>> So this is in some universe without causality? Must be quantum effects. >>> >> >> Someone replaced Schrödinger's cat with tomcat in a "gedanke" experiment >> :) >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
