-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Peter,
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. *shrug* >> 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 stopping. 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 -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl44g0kACgkQHPApP6U8 pFhpxQ//bbjQdDYMmgVmwvF0CwVVmSGSFmNi4slpOX1Ib+HHomB+QTdzL5596vmA rzStPuQUQ7JrlZF40GKGEqTJo+zmvyk4G+PhJ1/cM1GMYvUI3UhdZTX2aELLzFRu hwn/02v/mxr4TwPegSSTcAskkmZZGA8/7852fWpN03CaFcSunLusXRCsarIK1b22 VF5gbH5ZkcMj6ZtqPNqG2phJQBlQe6bZnZ6GduEEF050IHTwLk/AT/L5qrr/4H32 +WAmd9aq8BE3GJC4bqGcqgCaWvE6gmTaVrN51bEKjEhM2RlyGTapfsMHz7X9Gpo5 QsqlzkyUYrOtoLV9O+XMiIVa147ujSwvInMpYCU9PJf9Q/0VmGk07TQDMNtL7EdH EXNx6kYXgo2NSiKJBniKUACCc2KGkRd4l67tlUN8JYZGTbp1BqVIuX95WIQ6R4q3 hxq3/J8bV+eTydoU+YP4q4nNrBo2L53UlhXhMqG+3e9nebdtPvSTMYBF+ewB3w8F m4YexEDmOIG7sfBnziWPOYCcEG3Uvxx2U1r7+3J/zrW6LOF8UmdMwB4bibk1AGgy MFLzUmr2lfDl4XQ9AAxrrnSfdkhs0NmjV8PIvPkn2RSW+XL166Js3wxoJiSb7jkX XILiQ5vPxxaMQ20+n4okc18RQLIPMneZC1am8X0UW7RKGYOLDMo= =GBhu -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
