-
Notifications
You must be signed in to change notification settings - Fork 762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
undeploying existing web app causes other web apps go blank in multiple war files environment #3389
Comments
The log file contains lot of noise due to #3384. This issue may actually be slowing the deploy. I wonder if removal of a .war file is supported way how to undeploy a web application in Tomcat. Why don't you undeploy the webapp first using the application manager ? |
I assume that the |
Browsing the log I don't see any indication of times in minutes (modulo the overall time):
and
|
Could you try with 1.5.10 ? |
I tried with 1.5.10 but got the same symptom/results unfortunately. Let me add some for your questions.
Thank you very much for your support! |
Looking at
I was hoping that the fix for #3384 in 1.5.10 would shed some time during the deploy (generating log entries for all these exceptions takes some time). To benefit from that all the applications within the container would have to be upgraded. Anyhow, I don't see any significant times, everything is in matter of seconds:
and
What are these times in the production instance ? How do you measure the Tomcat restart time exactly ? It would be good idea to take a look at the Tomcat process in terms of I/O and CPU load during these 40 minutes with the usual tools. |
Back to the original problem: To reproduce this:
At this point I checked that both web apps display the usual OpenGrok index page on http://localhost:8080/foo/ and http://localhost:8080/bar/. Then I triggered undeploy of
Looking into the logs I can see this exception:
Obviously It looks as if there was some routing/sharing/caching problem in Tomcat. |
When I did the 'Reload' on the |
If |
Looking at
and then the request to
When the request is being dealt with, the following .jar files are being opened:
So, |
These 2 lines in the stack trace are interesting:
so perhaps this is some broken caching in Tomcat. It is still a question why it needs to stat the same file again. |
After reviewing bunch of Tomcat caching related questions on Stackoverflow I created https://stackoverflow.com/questions/65126838/how-to-prevent-tomcat-from-accessing-jar-files-from-undeployed-web-application |
Tried to disable the caching by putting: <Resources antiResourceLocking="false" cachingAllowed="false" /> into
That matches 208 protected WebResource getResource(String path, boolean validate,
209 boolean useClassLoaderResources) {
210 if (validate) {
211 path = validate(path);
212 }
213
214 if (isCachingAllowed()) {
215 return cache.getResource(path, useClassLoaderResources);
216 } else {
217 return getResourceInternal(path, useClassLoaderResources);
218 }
219 } |
RHEL: 7
Tomcat: 9.0.13
jdk: 11.0.2
ctags: built on 01/15/19
opengrok: 1.5.9
We are having multiple war files under tomcat/webapps directory and each war file contains one branch (no project enabled).
I notice that if I remove existing war file, tomcat shows blank screen when I go to branches's root by click the remainng
branch from tomcat web application manager. (e.g. url is hostname:port/test2/) However, if I go to xref by typing in url
field of the browser, correct screen is displayed. (e.g. url is hostname:port/test2/xref/) I need to restart tomcat to
workaround this issue.
This issue was started to appear around 1.4.7, 8, or 9.
I also notice that tomcat restarting time gets extraordinally increased (from 8 min to 40+ min; with 70 war files) starting from above these releases, too.
So, restarting tomcat to fix this issue is not a good option for us.
Recreation Steps:
[
catalina.2020-12-02.zip
](url)
I am attaching catalina.log. (sorry for the big file)
I can see "java.nio.file.NoSuchFileException: /opt/pisces/ogtest/webapps/test1/WEB-INF/lib/tablesorter-2.31.3.jar" at the last.
The text was updated successfully, but these errors were encountered: