Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shutting down gracefully after all current requests have been closed #65

Open
derFunk opened this issue Aug 30, 2016 · 2 comments
Open

Comments

@derFunk
Copy link
Contributor

derFunk commented Aug 30, 2016

As far as I can see it seems that there is no real graceful shutdown implemented for the Listeners.
After sending a SIGTERM/SIGINT, HFC is not waiting for all current web requests to be processed, right?

This results in several exceptions when stopping HFC, e.g. ThreadAbortExceptions, e.g. when ServiceStack is being used.

Would it be possible to implement this in general?:

  • After receiving a SIGTERM/SIGINT, don't accept new incoming connections but answer with a dedicated http error code
  • After receiving a SIGTERM/SIGINT, still process the currently active requests
  • After all requests have been processed, finally shutdown the listener and exit the process.
@xplicit
Copy link
Owner

xplicit commented Aug 30, 2016

HyperFastCGI do it exactly the same way like ASP.NET does - aborts currently running threads and shuts down the application. If it will wait till all requests are served it will never be stopped in case of long-polling HTTP requests. Moreover some of thread aborts (for example reloading app domain when changing web.config) cannot be controlled by HyperFastCGI because are managed directly by mono implementation of System.Web and HyperFastCGI just be notified from System.Web that domain is unloading.
However it's possible to make improvement to stop receive incoming connections and wait some small amount of time after SIGTERM to process working requests.

@derFunk
Copy link
Contributor Author

derFunk commented Aug 31, 2016

Ok, thanks. Regarding long polling requests - it should be able to recognize these connections, right? these could/should be simply closed then, whereas non-long-polling ones should wait until they have been processed (which can take a while, e.g. 60s, I agree).

Maybe introducing the "graceful connection shutdown" behaviour could be introduced by an optional command line argument.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants