From: Eric Wong <email@example.com> To: Simon Eskildsen <firstname.lastname@example.org> Cc: email@example.com, Jeremy Evans <firstname.lastname@example.org> Subject: Re: after_worker_exit on murder Date: Wed, 5 Apr 2017 01:19:32 +0000 Message-ID: <20170405011932.GA24739@starla> (raw) In-Reply-To: <CAO3HKM6SuoR8oFDQ=rafegWVXWj+84_ekQCSm9-6NOoD9OcwiQ@mail.gmail.com> Simon Eskildsen <email@example.com> wrote: > With Jeremy Evans' work on `after_worker_exit`, I was hoping I could > replace our internal fork which has a `before_murder` hook to report > to monitoring systems when workers are forcibly killed. However, the > `after_worker_exit` is only called on reaping—not when murdering. Hi Simon, it looks like Jeremy clarified after_worker_exit for you. Anyways... I remember rejecting patches to add more to timeout support in unicorn over the years since I did not want it to be a crutch for application developers, or worse; a reason for people to feel locked into unicorn. Instead I wrote things like https://bogomips.org/unicorn/Application_Timeouts.html to discourage relying on unicorn's built-in `timeout' feature. But, it seems like there's still a reliance on the built-in timeout... Why is that? (If you're allowed to disclose) I don't mean to put you guys (Shopify) on the spot, as I'm sure other folks do it, too; but you're here :) Anyways, is this something that could or should be improved in Rack or ruby itself? Or are there buggy external libraries or even external dependencies like NFS to blame? (Or, perhaps "I don't know" is fine :) The Ruby timeout handling in stdlib could be way better if done natively, I think. Perhaps `ensure` could be better declared, too; but there's still the problem of getting external code to work well with it... Anyways I am of two minds; on one hand, buggy code is fine! unicorn handles it by nuking a process. But on the other hand... it's irritatingly inefficient and shoving things under the rug still rots and stinks eventually.
next prev parent reply index Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-04-04 14:08 Simon Eskildsen 2017-04-04 14:32 ` Jeremy Evans 2017-04-04 14:36 ` Simon Eskildsen 2017-04-05 1:19 ` Eric Wong [this message] 2017-04-05 10:55 ` Simon Eskildsen 2017-04-05 18:33 ` Eric Wong
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://bogomips.org/unicorn/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20170405011932.GA24739@starla \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help Archives are clonable: git clone --mirror https://bogomips.org/unicorn-public git clone --mirror http://ou63pmih66umazou.onion/unicorn-public Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.lang.ruby.unicorn nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.unicorn note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox