> Does it ever work?

Yes, I deployed and redeployed much larger WARs (i.e. 107MiB) many times to the 
same instance.

> The Tomcat manager has a default limit of 50MiB for uploads. Your WAR
> file it larger than that, so it might be failing.

Some weeks ago I changed this default limit to "about" 500MiB - as I always do 
(!!). To give you the 100% prove I send you the max-file-size-config:


> The /second/ upload in your log file might be because the deployer
> re-tries when the first attempt fails. 

Hm, if the plugin retries to upload I expect some logging output. Even if there 
is no debug-output for the retry, I could try to debug it locally.

> It's so fast because Tomcat
> rejects the request immediately after looking at the Content-Length,
> instead of allowing 71MiB of stream over the network before rejecting
> the request.

This can not be true, how would you tell the existance of this line in the log?:

   02-Feb-2020 16:57:06.466 INFO [http-nio-80-exec-5] 
org.apache.catalina.core.ApplicationContext.log Manager: deploy: Deploying web 
application 'XXX'

If - and only if - a WAR is rejected because of its size, the Manager would 
never ever write "Hey dude, I am deploying your web application XXX!". Right?

Anyway I found it by myself.

> On 2/2/20 4:48 PM, Peter Rader wrote:
> > The old version of the application had a daemon that have not yet
> > finished his execution.
> Tomcat cannot detect this situation, so it's unlikely to be the direct
> problem. 

I see.

> How did you come to your conclusion?

I noticed two hints that guides me to this idea:

1. I configured a user having the role manager-gui and tried to stop the 
web-application using the manager-web-interface (/manager/html/list). Stop 
command was not successfull, a error message occoured above the 
2. I could send the SHUTDOWN signal successfully, all looks like a clear 
shutdown (the connectors successfully shutting down, CDI shutdown, 
EntityManager closed, port 80+443 becomes free, sessions passivated) but the 
java-process remains running for no reason and must be killed manually.
3. Last but not least, the original problem: The webapp fails to redeploy using 
mvn tomcat:redeploy.

> - -chris


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to