On Wed, Sep 23, 2015 at 4:30 PM, Eric Wong <e...@80x24.org> wrote: > "Lin Jen-Shin (godfat)" <god...@godfat.org> wrote: >> However instead of setting shutdown_timeout, I think I would probably >> need to make the application know that the server is shutting down, >> and stop right there instead of waiting for full 60 seconds. >> >> Not sure if I could do this without talking to yahns directly... > > This is a Rack app? I really don't want to introduce custom APIs for > this which would lock Rack users down to yahns.
Yes this is a Rack app. I totally understand locking down to a specific webserver would not be so good, but sometimes I really want to make the best tweak so I'm personally ok with some specific configuration, especially given that I realized switching to a different server could mean some other configuration should be changed as well. The most recent example is database connection pool size. With a threading server, I could set the size to a very large number, but for a forking server like Unicorn, the size should be much lower. So to switch servers, we already need to make a few changes accordingly. (detecting would be even more works :() > I suppose you could chain signal handlers, though: > > orig_quit = nil > orig_quit = trap(:QUIT) do > app_specific_quit > orig_quit.call > end > > (Ditto for TERM/INT, totally untested) Just tried it, but not sure where to put this. With preload=true, yahns is trapping later than the application. Maybe I should just set it to false since we're not forking anyway... -- unsubscribe: yahns-public+unsubscr...@yhbt.net archive: http://yhbt.net/yahns-public/
