Hash: SHA256


On 2/3/20 2:10 PM, Peter Rader wrote:
>> 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:
> <multipart-config> <max-file-size>5242880000</max-file-size> 
> <max-request-size>5242880000</max-request-size> 
> <file-size-threshold>0</file-size-threshold> </multipart-config>

LGTM, though you might want to set file-size-threshold to something
other than zero. 500MiB is a lot of wasted heap space to store a WAR
file's contents :)

Just to confirm: this is in the manager's WEB-INF/web.xml file?

>> 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'

Fair enough.

> 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 application-table.
What was the error?

> 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.
Well, that's no "no reason", but your application leaving a non-daemon
thread running. This rarely if ever prevents a web application from

You should really look at implementing a ServletContextListener to
clean this up on application stop. In fact, that thread should be
launched from the ServletContextListener on startup and shut-down in
the same class for symmetry.

If it's something like a Quartz timer (as it often is when this kind
of thing is reported), then you might have to do some kind of
initialization that you weren't already doing -- allowing Quartz to
lazily auto-initialize -- so that you can properly shut it down, later.

> 3. Last but not least, the original problem: The webapp fails to 
> redeploy using mvn tomcat:redeploy.

Well, the failure to redeploy (actually, failure to deploy, right?!)
isn't caused by your application's failure to stop, because, well:

> 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'

Tomcat isn't in the business of deploying an application while there
is still an application deployed with the same name (unless you are
using parallel deployment, which is a different story, and you didn't
mention that).

So the problem is with the deployment, not the undeployment. Seeing
two lines in the log file about PUT statements might just be due to a
failure on the initial deployment. You didn't post the whole log file,
so I can't be sure what is showing after the second "PUT" log.

- -chris
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/


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

Reply via email to