I have a web application that is deployed in Jetty 11.0.2. I have a ServletContextListener registered in web.xml,
<listener>
<description>A listener that starts and stops all managed services based on the lifecycle of the web application context.</description>
<display-name>Service Management Listener</display-name>
<listener-class>com.bb.base.webservices.servlets.services.ServiceManagementListener</listener-class>
</listener>
When jetty starts and my web application is deployed, the contextInitialized(...) method is being called, however when I shut down jetty using kill -s TERM ${JETTY_PID} the contextDestroyed(...) method is not being called. In my server.ini file, I have enabled graceful shutdown with,
jetty.server.stopAtShutdown=true
jetty.server.stopTimeout=15000
When jetty shuts down I am seeing it do the clean shutdown. I see;
2021-05-01 05:19:16.605:INFO :oejs.Server:JettyShutdownThread: Stopped Server#7a6d7e92{STOPPING}[11.0.2,sto=15000]
2021-05-01 05:19:16.606:INFO :oejs.Server:JettyShutdownThread: Shutdown Server#7a6d7e92{STOPPING}[11.0.2,sto=15000]
2021-05-01 05:19:16.630:INFO :oejs.AbstractConnector:JettyShutdownThread: Stopped ServerConnector#60db1c0e{SSL, (ssl, http/1.1)}{0.0.0.0:8443}
2021-05-01 05:19:16.631:INFO :oejs.AbstractConnector:JettyShutdownThread: Stopped ServerConnector#3b5fad2d{HTTP/1.1, (http/1.1)}{0.0.0.0:8080}
2021-05-01 05:19:16.631:INFO :oejsh.ContextHandler:JettyShutdownThread: Stopped o.e.j.s.h.ContextHandler#2dd80673{/.well-known,null,STOPPED}
2021-05-01 05:19:17.093:INFO :oejsh.ContextHandler:JettyShutdownThread: Stopped o.e.j.w.WebAppContext#c5dc4a2{Fermenation,/,null,STOPPED}{/opt/fermenation/live/jettyCfg/code/services-3.4.4.war}
The last line being the shutdown of my web app context. However, my listener is never called.
This logic used to work in earlier versions of jetty. I am pretty sure it worked in jetty 9.4, however I unfortunately don't have the log files anymore so I can not see it for certain. May have been an earlier version of jetty when I implemented this to begin with which is the only time I know beyond a doubt it worked.
I would appreciate any suggestions anyone has. Can't figure out why this has stopped working.
Shutdown logic... You never know it is broken until it is a serious problem that it is broken.
Related
I'm developing on Mac OSX 10.8. Lately I've been noticing that when I've been running the dev server for a while, and then -C to exit, the process continues to run in the background. I have to do a ps to find the process and kill it, or it won't let me use the same address:port again.
I didn't have to do that in earlier versions of Django (I'm currently running 1.7.3 on this project). Seems a bit messy, but don't know of another way to stop the dev server and free the port/resources?
Rgds,
Ross.
Django development server have multiple threads, so when closing main process, there might be some running threads in background. It happens when there is some request being processed (some long-term request can hang or if you're using websockets or something, connection might prevent closing thread).
Check if all of your requests are properly closed before closing your server and it should shut down properly.
I am currently using Jetty 9.1.4 on Windows.
When I deploy the war file without hot deployment config, and then restart the Jetty service. During that 5-10 seconds starting process, all client connections to my Jetty server are waiting for the server to finish loading. Then clients will be able to view the contents.
Now with hot deployment config on, the default Jetty 404 error page shows within that 5-10 second loading interval.
Is there anyway I can make the hot deployment has the same behavior as the complete restart - clients connections will wait instead seeing the 404 error page ?
Unfortunately this does not seem to be possible currently after talking with the Jetty developers on IRC #jetty.
One solution I will try to use are two Jetty instances with a loadbalancing reverse proxy (e.g. nginx) before them and taking one instance down for deployment.
Of course this will instantly lead to new requirements (session persistence/sharing) which need to be handled. So in conclusion: much work to do in the Java world for zero downtime on deployments.
Edit: I will try this, seems like a simple enough solution http://rafaelsteil.com/zero-downtime-deploy-script-for-jetty/ Github: https://github.com/rafaelsteil/jetty-zero-downtime-deploy
I am getting intermittent errors -
child process XXX still did not exit, sending a SIGTERM.. and then a SIGKILL. It occurs intermittently and the web page hangs.
I was not using Daemon process..but now I am, still the problem exists..
Also I have some Error opening file for reading: Permission Denied.
Please can someone help?
I am new to this forum, so sorry if that has been answered before.
If you were not using daemon mode of mod_wsgi, that would imply that Apache must have been restarted at the time that initial message was displayed.
What is occurring is that in trying to do a restart, Apache sends a SIGTERM to its child processes. If they do not exit by their own accord it will send SIGTERM again at 1 second intervals and finally send it a SIGKILL after 3 seconds. The message is warning you of the latter and that it force killed the process.
The issue now is what is causing the process to not shutdown promptly. There could be various reasons for this.
Using an extension module for Python which doesn't work in sub interpreters properly which is deadlocking and hanging the process, preventing it from shutting down. http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
Use of background threads in the Python web application which have not been set as being daemon threads properly with the result they are then blocking process shutdown.
Your web application is simply trying to do too much on process shutdown somehow and not completing within the time limit.
Even if using daemon mode you will likely see this behaviour as it implements a similar shutdown timeout, albeit that the timeout is configurable for daemon mode.
Anyway, force use of the main Python interpreter as explained in the documentation link above
As to the permissions issue, read:
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Access_Rights_Of_Apache_User
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Application_Working_Directory
In short, ensure access permissions are correct of files/directories you need to access and ensure you are always using absolute path names when accessing the file system.
I have created a console application that runs through a windows service.
Service starts the application and runs it well.
The problem is when i attempt to restart/shutdown my PC, application is closing before the actual shutdown.
So what happens is the service restarts the application again before shutdown.
Even I tried without service. Application is closing before shutdown.
How can I tell my service to know that pc is going to shutdown/restart. So dont restart the application.
Can anyone help me with this ?
Your service can register for notification with RegisterServiceCtrlHandlerEx and will receive the SERVICE_CONTROL_PRESHUTDOWN notification when the shutdown process begins. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms685149(v=vs.85).aspx for more information.
I have a Windows service written in CPP that I start manually. The service starts up just fine and works ok. However we have recently noticed in the Windows Services GUI that the service shows in the Starting state. Upon examining the Event Viewer it clearly shows that the service has entered the Running state.
Anyone got any nuggets of gold on this one?
Thanks.
The problem turned out to be an unaccounted for call to the SCM to start the service. Deleted the line and the problem went away.