Bug 58187

There have been no changes to the manager package in 7.0.x since 7.0.58 and the change then was to simply update the copyright year to 2015.

The Manager will not write a response until the start() event has completed for the Context. If Context.start() throws an exception, the Manager will report it.

It is possible for Context.start() to complete without exception but end up in the failed state. In this case the deployer will report successful deployment (the WAR was copied and deployed) but the Context will be listed as not running.

If you can provide a simple WAR file that demonstrates different behavior with 7.0.61 and 7.0.62 I'll take another look.

Created attachment 32979 [details]
Tomcat 7.0.61 normal deploy

Normal deployment process in Tomcat manager 7.0.61: application is deployed and Tomcat manager send the response after deployment.

Created attachment 32980 [details]
Disfunctional deployment on Tomcat 7.0.62

Disfunctional deployment process in Tomcat manager 7.0.62: application is deployed and Tomcat manager send the response BEFORE deployment.

The video is corrupt and can't be played (tested on multiple devices).

My previous comments stand. Without a WAR to demonstrate this issue, it will remain invalid.

Sorry the video can be read on Chrome (I just try now) by on Firefox it seems to considered it corrupted!

The WAR doesn't matter: for the video I take the jenkins.war that can be found here http://mirrors.jenkins-ci.org/war/latest/jenkins.war.

I called the URL xxxx/manager/text/deploy?path=/jenkins&war=c:/jenkins.war&update=true on Tomcat 7.0.61 and on Tomcat 7.0.62.

On Tomcat 7.0.61: application is deployed and Tomcat manager send the response after deployment.

On Tomcat 7.0.62: Tomcat send the reponse and the application is deployed after the notification.

Have you tried before putting it invalid and resolved ? I know that you should have plenty of bugs not accurate but here, it seems to be legitimate.

I will inspect the source code to find out the bug and if I submit a patch, will you accept it ?

Yes, I have tested it. I have also spent a fair amount of time reviewing the code changes.

There are several reasons why I am resolving this as invalid.

1. No steps have been provided to reproduce this on a clean Tomcat install. I've attempted to look at the videos on a range of platforms and browsers and all of them fail. Even if they did work, I doubt they would provide all of the necessary information.

2. The suggested test WAR (Jenkins) deploys and starts for me on 7.0.HEAD once I increase the upload limits for the Manager and run on Java 7.

3. There were no code changes to the relevant parts of the code between 7.0.61 and 7.0.62.

4. The behaviour when deploying jenkins when running on Java 6 is exactly the same in 7.0.61 and 7.0.HEAD. The Manager reports OK but Jenkins is not started.

Notes:
a) My previous statement that the Manager would report any excpetion thrown by context start was incorrect. It will report 'OK' for the deployment (by design and unchanged from 7.0.61) but the app will show as not started.

b) The necessary changes to the upload limits is one of the steps to reproduce missing from this report.

c) The requirement to use Java 7 was also missing from the report


At this point I would be very surprised if there was a valid bug to be found here. Please do not re-open this report unless you can provide the following:

1. A WAR (as small as possible) or a link to a WAR that triggers different behaviour on Tomcat 7.0.61 compared to one of:
- 7.0.62
- the latest stable 7.0.x release
- the latest 7.0.x code build from svn

2. The configuration changes to apply to the clean Tomcat installs (they must be identical for both) before attempting the deployment test.

Thank you for the time you spend for this report. I will try to be the more precise I can. 

Steps to reproduce:

On Tomcat 7.0.61:
- Take the Tomcat v7.0.61 from the archives
- Don't change anything to configuration (all parameters are leaved to default values (autoDeploy is true for example)) except the tomcat-users.xml file to access the manager
- Put the WAR provided in the webapp folder to start it as soon as Tomcat starts
- Start the Tomcat servers and wait for it completes its start (and the deployment of all applications)
- Call the URL http://localhost:8080/manager/text/deploy?path=/sample&war=file:C:/sample.war&update=true with the same WAR that has been dropped in webapp folder (of course the paths need to be adapted)
- See that on browser, the OK response appears AFTER the undeploy and redeploy of the WAR provided

On Tomcat 7.0.62:
- Take the Tomcat v7.0.62 from the archives
- Don't change anything to configuration (all parameters are leaved to default values (autoDeploy is true for example)) except the tomcat-users.xml file to access the manager
- Put the WAR provided in the webapp folder to start it as soon as Tomcat starts
- Start the Tomcat servers and wait for it completes its start (and the deployment of all applications)
- Call the URL http://localhost:8080/manager/text/deploy?path=/sample&war=file:C:/sample.war&update=true with the same WAR that has been dropped in webapp folder (of course the paths need to be adapted)
- See that on browser, the OK response appears BEFORE the undeploy and redeploy of the WAR provided


Platforms tested:
- Windows 7
- Linux Ubuntu 10.04
- JDK 1.7.0.67


War file:
https://tomcat.apache.org/tomcat-7.0-doc/appdev/sample/


What I mean by the response appears BEFORE is that the method "writeDeployResult" of the "ManagerServlet" is called BEFORE methods "undeploy" and "deployWAR" of the HostConfig class are called.

I have searched in the source code why the behaviour have changed and you are totally right: it's not the manager that have changed but the org.apache.catalina.startup.HostConfig class that causes the change of behaviour (due to correction of another bug).


The change in source code is this one : 

On Tomcat 7.0.62:
....
// File.lastModified() has a resolution of 1s (1000ms). The last
// modified time has to be more than 1000ms ago to ensure that
// modifications that take place in the same second are not
// missed. See Bug 57765.
if (resource.lastModified() != lastModified && (!host.getAutoDeploy() || resource.lastModified() < currentTimeWithResolutionOffset)) {....

On Tomcat 7.0.61:
....
if (resource.lastModified() > lastModified) {....

I will not reopen that bug but let your reopen it if you considered it as a bug but definitively, there was a change in the code that have an impact on the deployment of application.

Yep, that is a bug. Thanks for providing the necessary detail. The call to check(String) should be triggering a redeploy but it isn't because of the additional '1s' test.

Fixed in trunk, 8.0.x (for 8.0.27 onwards) and 7.0.x (for 7.0.65 onwards).