I don't know if the problem that I'm having is the same as yours, but I have to kill and restart tomcat every other day or so. I've actually made a cron that restarts tomcat nightly now. Problem solved, right? ;-) Now I'll never know if I ever fix it. :-(
See my other post to the similar thread that just started today by Beat De Martin:
Subject: apache, mod_jk, tomcat hungs
BTW, I'm using Unix sockets, because I thought I read somewhere that they are faster, but I wouldn't count on that being true, since JNI is still required for some reason on top of that... maybe they were supposed to be faster in theory since you wouldn't have to load JNI, but I don't think unix sockets will work without JNI. I would have switched to normal TCP Sockets by now, but I keep reading of people like you who are having the same problems I'm having.
Daniel Gibby
Adrian Barnett wrote:
Hi,
I'm having an annoying memory leak problem in tomcat5 on Redhat 9. The memory gradually creeps up until the JVM runs out of memory. (I've been using JMeter to send thousands of requests to tomcat)
Now, if I run the tests against tomcat by itself (via port 8080) it is fine and stable, the problem only occurs when I use port 80 to go via Apache.
After trying numerous different things, suspicion falls on mod_jk2. The docs on mod_jk2 are not very helpful. Some say that mod_jk2 is better than mod_jk and should be used in place of it, others say that mod_jk2 is not stable enough for production use yet and mod_jk should be used instead.
Also, we are using the JNI mode of communication for mod_jk2, rather than Unix sockets.
So, my questions are: 1) Which is safest - mod_jk or mod_jk2?
Neither? I'd really say neither would be safest.
2) Are there docs which describe when/why you should JNI or Unix sockets (or any other method), and what the advantages/disadvantages are?
Probably so, but I can never find them when I need them. And the "official" docs don't do the job very well.
3) Anybody got any other clues as to what could cause a leak like this? (I've searched many tomcat mail archives but found nothing of use)
Cheers, Adrian Barnett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
