I installed tomcat 9.0.14 on my system(Windows 10, Windows server 2016 R2)
I've no issue while starting the tomcat service(start in 2-3 sec).
However, it takes 1 minute to stop.
I thought one of my project residing under webapps is taking time so I removed all my project but result is same.
After that I make it empty webapps folder empty to check further still tomcat took 1 min to stop.
I check the log file and their are no errors.Tomcat is idle for 1 minute while stopping.
Common-deamon.log-------
[2019-01-08 16:30:02] [info] [13948] Stopping service...
[2019-01-08 16:30:03] [info] [13948] Service stop thread completed.
[2019-01-08 16:31:03] [info] [ 1940] Run service finished.
[2019-01-08 16:31:03] [info] [ 1940] Commons Daemon procrun finished
catalina.log--------
08-Jan-2019 16:30:02.399 INFO [Thread-6] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["http-nio-8080"]
08-Jan-2019 16:30:02.431 INFO [Thread-6] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["ajp-nio-8009"]
08-Jan-2019 16:30:02.453 INFO [Thread-6] org.apache.catalina.core.StandardService.stopInternal Stopping service [Catalina]
08-Jan-2019 16:30:02.453 INFO [Thread-6] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["http-nio-8080"]
08-Jan-2019 16:30:02.453 INFO [Thread-6] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["ajp-nio-8009"]
Is their any way I can reduce the sopping time of tomcat 9.
In tomcat 8 stopping time was 3-5 sec
Any help is appreciated.....
I was abel to reproduce this by
Downloading and extracting the apache-tomcat-9.0.14-windows-x64.zip
cd to apache-tomcat/bin
service.bat install
Starting the Service is quick, stopping it delays exactly 60 seconds.
This seemes to be an issue of Tomcat, but current developer snapchot (trunk) changelog suggests it has been already fixed for not yet released Tomcat 9.0.15+ without explicit bug report assigned:
Tomcat 9.0.15 (markt) in development / Catalina:
Correct a bug exposed in 9.0.14 and ensure that the Tomcat terminates in a timely manner when running as a service. (markt)
We had the same problem with Tomcat v9.0.26. Tomcat took exactly 60 seconds to finish once you terminated the server. We tried hard to close and shutdown everything we had in our application and in the end we realized we had a ThreadPoolExecutor that created a newCachedThreadPool() and this cachepool has a "keepAliveTime" of 60 seconds.
So after terminating the tomcat the threadpool was waiting 60 seconds to check if the threads are still needed to be reused. Only after this time it really shut down. So the solution was to shut down the cached thread pool once we shut down the application.
Related
Dears,
I have a jersey - spring api deployed on apache tomcat 9.0.46. (Jersey to handle restful services JAX-RS and Spring to handle all my beans{controllers, DAO, SessionFactory, JPA etc...}).
Everything works fine on tomcat 9 on windows...
When deploying the exact same war in ubuntu tomcat 9.0.46, the ContextLoader is getting triggered 3 times and I have all my singletons instantiated 3 times. I'm deploying the api on tomcat ports 80 and 443 (https - godady certificate).
once I start tomcat the war is deployed and ports 80 and 443 get started (netstat -tulnp | grep java) and I see in log all singletons instantiated. (pool-2) Applicationcontext class my custom spring #Configuration class and it is getting triggered and DB is accessed without any issues
2021-06-09 14:41:52,128 1104 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 905 ms
2021-06-09 14:41:53,124 2100 [pool-2-thread-1] INFO skd.app.core.ApplicationContext - TASK::cleanExpiredStatuses
then the server takes few minutes (around 10 minutes 14:41 above then 14:51 below) and when port 8005 is started I see again the ContextLoader is triggered again 2 times.
09-Jun-2021 14:51:36.196 WARNING [main] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [584,064] milliseconds.
09-Jun-2021 14:51:36.592 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:37.042 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war] has finished in [588,185] ms
2021-06-09 14:51:39,388 696 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 581 ms
09-Jun-2021 14:51:39.632 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:40.013 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war]
and again for the 3rd time:
2021-06-09 14:51:41,989 744 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 605 ms
09-Jun-2021 14:51:42.232 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:42.602 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war] has finished in [2,590] ms
Everything is working fine in windows, only when deploying to ubuntu tomcat, I'm getting this.
Does anyone have a clue why this difference in tomcat behaviour between windows and ubuntu for the same exact WAR file?
I have managed to figure out the problem. The issue was related to tomcat configuration in /conf/server.xml. Multiple Hosts will trigger the context loader to be triggered for each. I was keeping the default appBase to webapps for all host thus triggering the ContextLoader of each my war for each host. Another reason the ContextLoader will triggered multiple times as well is defining the option inside unless you need to load something external to your war.
I recommend reading specs:
https://tomcat.apache.org/tomcat-4.1-doc/config/host.html
My Grails 4 application, deployed to GCP appears to be trying to start up after being deployed but never comes up properly. Application requests return a 500 response. There are no errors or clues with DEBUG log level output at the root level.
The same application runs fine locally in development mode.
The production configuration is as per the Grails 3 deployment (to GCP) guide except for the adjustments that were necessary to make it work for Grails 4/Java 11.
Most of the bootstrapping appears to carry out as expected;
Spring Security configures successfully
Spring Security REST configures successfully
Spring beans are registered
Connects to Cloud SQL instance
Database schema is created (by Liquibase)
Plugins are loaded successfully
Then it gets to the following familiar lines of output logging;
INFO --- [main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)
INFO --- [main] o.a.coyote.http11.Http11NioProtocol : Initializing ProtocolHandler ["http-nio-8080"]
INFO --- [main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
INFO --- [main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.17]
and restarts..
while normally, the next phase of bootstrapping (happens locally) would be;
[restartedMain] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
[restartedMain] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 42018 ms
Probably a long shot question but any level of clues or suggestions would be much appreciated.
I've run out of doors to open. :-(
You could try to update Tomcat version just in case.
But looking at Grails documentation:
https://docs.grails.org/latest/guide/upgrading.html
There's some configuration made when you upgrade to Grails 4 from
Grails 3.3.x to prevents the server from restarting when views or
message bundles are changed.
Either modifying a gsp in Grails 4 M2 cause the application to restart.
https://github.com/grails/grails-core/issues/11284
I'm currently evaluating CloudControl as platform provider for my Java based applications.
I created a very simple Spring Boot (https://github.com/mhmpl/gradle-example-app) app with Gradle but I'm unable to deploy the app.
There are no errors in the Error log which could give me some information. However, this is the output of the Deploy log:
8/3/14 12:53 PM lxc-1272 INFO Container did not come up within 120 seconds.
8/3/14 12:53 PM lxc-1250 INFO Waiting for the container to be reachable...
8/3/14 12:53 PM lxc-1272 INFO Waiting for the container to be reachable...
8/3/14 12:52 PM lxc-1250 INFO Waiting for the container to be reachable...
8/3/14 12:52 PM lxc-1272 INFO Waiting for the container to be reachable...
8/3/14 12:52 PM lxc-1250 INFO Waiting for the container to be reachable...
8/3/14 12:52 PM lxc-1272 INFO Waiting for the container to be reachable...
8/3/14 12:51 PM lxc-1250 INFO Deploying ...
Finally, the app is not deployed and I cannot see an error which I've potentially made. I already tried to set the memory to 1024MB and added a second container, but that did not change anything at all.
You need to bind the webserver to the correct port, which is defined in the PORT environment variable.
When I try to start Apache tomcat 7.0.26 server is not starting. This is first time.
console message as follows :
Mar 7, 2012 12:06:18 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 470 ms
It has been started and the starting process took 470 ms.
That's what the message says.
I have the suspicion that you didn't even bother to check the url of web management to see if Tomcat is up or not.
Tomcat: 6.0.20.0
OS: Windows Server2003
Architecture: x86
JVM: 1.5.0_19
We have a Tomcat instance that looks to be shutting down unexpectedly. The logs look like the following:
[DATE] org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080
[DATE] org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
[DATE] org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
There are no exceptions such as out of memory in the logs. It looks like a clean graceful shutdown. The code in our app has been checked for System.exit(). Also nothing should be sending SHUTDOWN to port 8005.
We have a service wrapper in c# that calls a .bat with start/stop commands which in turn call catalina.bat. The service still shows Tomcat as running whenever Tomcat shuts down unexpectedly. The App logs do not log the service shutdown when it's unexpected but logs shutdowns manually done through the service in Windows.
Tomcat Manager is not configured.