You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Justin Miller <ju...@utah.gov> on 2011/12/06 17:38:48 UTC
unpackWARs and antiResourceLocking
Windows 2008 64-bit
Java 1.6.0_16 32-bit
Tomcat 6.0.33
Greetings
I'm having some difficulties with the above environment and setting unpackWARs = "false" antiResourceLocking = "true" with apps packaged as WAR files. It appears that Tomcat is attempting to copy the WAR from the $CATALINA_HOME/webapps directory to the $CATALINA_HOME/temp directory without the .war extension (e.g., original docBase is $CATALINA_HOME/webapps/example.war and a new docBase of $CATALINA_HOME/temp/1-example ). Is my understanding that with the unpackWARs setting set to false, Tomcat just runs directly from the .war? Additionally, with the antiResourceLocking set to "true", given the above assumption, would it be that Tomcat runs the app from a .war copied wholesale to the temp directory? If so, it appears that line 973 in ContextConfig.java method antiLocking never evaluates correctly because the docBase gets set to the value of path on line 969, which removes the .war extension so the file ends up being $CATALINA_HOME/temp/1-example instead of 1-example.war.
Additionally, applications with sub-context paths (e.g., foo#bar.war) never get deployed to temp correctly with antiResourceLocking="true" regardless of the unpackWARs setting because of the above scenario and because the docBase gets set to the context path in the antiLocking method which converts the # separator to /. There appears to be a fix on line 882 of fixDocBase that converts the / character to # in the path but that doesn't make it to the antiLocking method.
Please advise if I my understandings/assumptions are incorrect and if so, how I might configure Tomcat correctly to run a war without unpacking and locking resources. I am also happy to submit a bug report if needed.
Thanks in advance
Justin Miller
Re: unpackWARs and antiResourceLocking
Posted by Justin Miller <ju...@utah.gov>.
Thanks for the response. Both 6.0.35 and 7.0.23 exhibit the same behaviour. In 7.0.23, the docBase is changed back to the context path via the ContextName now instead of the context.getPath() but the result is the same. Interestingly enough, there is a comment in the 7.0.23 source on line 750 that suggests the code to copy the .war file is never reached and that it's possibly a bug. This code is never reached because the docBase is changed to the path without the .war extension. I will submit a bug report.
Additionally, I am running in a Windows environment and I use the antiResourceLocking on only a few apps so that new application war files may be deployed throughout the day (this is a test server) without bringing down Tomcat. I didn't use the JreLeakPreventionListener because only a few applications need to be re-deployed; everything else is pretty much static and I didn't want the performance hit with antiResourceLocking to affect every app. Is that reasonable or should I still just use the JreLeakPreventionListener?
Thanks again
Justin
>>> Konstantin Kolinko <kn...@gmail.com> 12/6/2011 10:21 AM >>>
2011/12/6 Justin Miller <ju...@utah.gov>:
> Windows 2008 64-bit
> Java 1.6.0_16 32-bit
> Tomcat 6.0.33
>
> Greetings
>
> I'm having some difficulties with the above environment and setting
> unpackWARs = "false" antiResourceLocking = "true" with apps packaged as WAR
> files. It appears that Tomcat is attempting to copy the WAR from the
> $CATALINA_HOME/webapps directory to the $CATALINA_HOME/temp directory
> without the .war extension (e.g., original docBase is
> $CATALINA_HOME/webapps/example.war and a new docBase of
> $CATALINA_HOME/temp/1-example ). Is my understanding that with the
> unpackWARs setting set to false, Tomcat just runs directly from the .war?
> Additionally, with the antiResourceLocking set to "true", given the above
> assumption, would it be that Tomcat runs the app from a .war copied
> wholesale to the temp directory? If so, it appears that line 973 in
> ContextConfig.java method antiLocking never evaluates correctly because the
> docBase gets set to the value of path on line 969, which removes the .war
> extension so the file ends up being $CATALINA_HOME/temp/1-example instead of
> 1-example.war.
>
> Additionally, applications with sub-context paths (e.g., foo#bar.war) never
> get deployed to temp correctly with antiResourceLocking="true" regardless of
> the unpackWARs setting because of the above scenario and because the docBase
> gets set to the context path in the antiLocking method which converts the #
> separator to /. There appears to be a fix on line 882 of fixDocBase that
> converts the / character to # in the path but that doesn't make it to the
> antiLocking method.
It sounds like a bug. If you can reproduce it, please file a bug report.
I would appreciate though if you can test with recently released
6.0.35 and with 7.0.23.
In 7.0.x the app name<->path handling was moved to a well-defined
helper class, so it is unlikely that the issue is present there.
>
> Please advise if I my understandings/assumptions are incorrect and if so,
> how I might configure Tomcat correctly to run a war without unpacking and
> locking resources. I am also happy to submit a bug report if needed.
1. Even if war itself is not unpacked, Tomcat has to extract jars from
it (otherwise it cannot feed them to class loaders).
2. Regarding whether or not it copies and were - I think it is easier
to run and see. It can copy things to /temp, but IIRC most times it
copies things to /work/Catalina/localhost/<appname>.
IIRC the TC7 docs were recently a bit clarified on the topic of those
options. I do not remember whether that was backported to 6.0 docs.
3. Usually you do not need those anti* flags. The
JreLeakPreventionListener (if you have it in your server.xml) changes
JRE defaults to keep JARs closed.
You also do not need the flags if you never undeploy the webapp while
Tomcat is running. (E.g. you never undeploy the manager webapp).
4. The anti* flags are needed on Windows only. On unixes you can
delete files that are kept open so this problem does not exist.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: unpackWARs and antiResourceLocking
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/12/6 Justin Miller <ju...@utah.gov>:
> Windows 2008 64-bit
> Java 1.6.0_16 32-bit
> Tomcat 6.0.33
>
> Greetings
>
> I'm having some difficulties with the above environment and setting
> unpackWARs = "false" antiResourceLocking = "true" with apps packaged as WAR
> files. It appears that Tomcat is attempting to copy the WAR from the
> $CATALINA_HOME/webapps directory to the $CATALINA_HOME/temp directory
> without the .war extension (e.g., original docBase is
> $CATALINA_HOME/webapps/example.war and a new docBase of
> $CATALINA_HOME/temp/1-example ). Is my understanding that with the
> unpackWARs setting set to false, Tomcat just runs directly from the .war?
> Additionally, with the antiResourceLocking set to "true", given the above
> assumption, would it be that Tomcat runs the app from a .war copied
> wholesale to the temp directory? If so, it appears that line 973 in
> ContextConfig.java method antiLocking never evaluates correctly because the
> docBase gets set to the value of path on line 969, which removes the .war
> extension so the file ends up being $CATALINA_HOME/temp/1-example instead of
> 1-example.war.
>
> Additionally, applications with sub-context paths (e.g., foo#bar.war) never
> get deployed to temp correctly with antiResourceLocking="true" regardless of
> the unpackWARs setting because of the above scenario and because the docBase
> gets set to the context path in the antiLocking method which converts the #
> separator to /. There appears to be a fix on line 882 of fixDocBase that
> converts the / character to # in the path but that doesn't make it to the
> antiLocking method.
It sounds like a bug. If you can reproduce it, please file a bug report.
I would appreciate though if you can test with recently released
6.0.35 and with 7.0.23.
In 7.0.x the app name<->path handling was moved to a well-defined
helper class, so it is unlikely that the issue is present there.
>
> Please advise if I my understandings/assumptions are incorrect and if so,
> how I might configure Tomcat correctly to run a war without unpacking and
> locking resources. I am also happy to submit a bug report if needed.
1. Even if war itself is not unpacked, Tomcat has to extract jars from
it (otherwise it cannot feed them to class loaders).
2. Regarding whether or not it copies and were - I think it is easier
to run and see. It can copy things to /temp, but IIRC most times it
copies things to /work/Catalina/localhost/<appname>.
IIRC the TC7 docs were recently a bit clarified on the topic of those
options. I do not remember whether that was backported to 6.0 docs.
3. Usually you do not need those anti* flags. The
JreLeakPreventionListener (if you have it in your server.xml) changes
JRE defaults to keep JARs closed.
You also do not need the flags if you never undeploy the webapp while
Tomcat is running. (E.g. you never undeploy the manager webapp).
4. The anti* flags are needed on Windows only. On unixes you can
delete files that are kept open so this problem does not exist.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org