On 06.03.2018 15:09, Kenneth Taylor wrote:

More troubleshooting revealed that our root context xml had been copied from another installation and had a wrong path in it.  However, I don’t think this was the problem since it was only a path to a Log4J config.  We re-installed Tomcat from scratch and it seems to have resolved it, but this is not good.  Why is Tomcat caching webapps?

Tomcat loads webapps into memory, in order to execute them. It doesn't cache per se, as has been stated by others already.

Also determined that Tomcat was not shutting down properly.  Our installation is deployed as a Windows Service.  Stopping the service did not stop Tomcat.  But the Service Console thinks it did stop, so when you restart it, another instance of Tomcat starts.  We are using a Java Service Wrapper if that makes any difference.

Windows is known to sometimes keep file locks forever - in fact, I've been in trainings where students didn't just need to restart a server, but needed to reboot the OS in order to get rid of a locked file. Only on Windows. Further, Tomcat does its best to shut down webapps. But if your webapps start their own non-daemon threads, the JVM doesn't shut down when Tomcat has long shut down. This, in turn, might keep file handles open, thus Windows-File-Locks (it's not always Windows that is to blame)

You'd have a point blaming tomcat for keeping references up, if you could reproduce your issues without custom webapps installed. I bet you can't, thus I'm seconding Mark with regards to the comment on your tone in your original post. And it doesn't really sound like you've read his reference.

Also found another problem.  The “-XX:+DisableAttachMechanism” JVM option does not work with Tomcat.  This is a security flaw.

please specify "does not work": Give steps to reproduce. Without them, this is just another rant assuming that you're perfect and all of the software around you is blamed for actively sabotaging your life


To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to