unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org>
To: mongrel-unicorn-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org,
	rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
Subject: dealing with client disconnects with TeeInput
Date: Thu, 12 Nov 2009 02:04:49 -0800	[thread overview]
Message-ID: <20091112100449.GA1929@dcvr.yhbt.net> (raw)

Foreword: this probably doesn't affect nginx+Unicorn users, which is the
recommended configuration for the vast majority of sites.  It probably
affects Rainbows! users using Thread* or Revactor the most, and probably
some Unicorn users serving Intranet clients directly.

When clients are uploading large files, there's always a good
possibility of them disconnecting before the upload ends.  For other web
app servers it's not much of a problem: they read the entire upload
before attempting to process things; so the app never sees a prematurely
disconnected client.

However Rainbows! and Unicorn have the TeeInput class which allows
real-time processing of uploads as they occur.  Now, we _want_ the
exception to be thrown and application to stop processing the dead
client request immediately.  I've made changes in unicorn.git and
rainbows.git to ensure no EOFError exceptions from the socket are
silenced, not just ones from reading trailers.

However, this means (many more) socket errors will be seen within the
application and any global exception trappers they use will see them as
well.  For Rails (and possibly other frameworks), this can mean very
messy log files with large backtraces.

So, would making a Unicorn::Disconnect < EOFError exception class and
raising it with a short/empty backtrace on EOFErrors be the best way to
go?  That way those global exception trappers can distinguish between
EOFError exceptions raised by Unicorn/Rainbows! itself and other code
that Unicorn/Rainbows does not care about, and log appropriately...

The other option we have is catch/throw.  We can avoid worrying about
the stack trace entirely, and middlewares that opt-in can still capture
and log the disconnect if they want to.  More maintenance overhead for
Rainbows! with all its concurrency models, but this is a situation
where I think catch/throw is appropriate for given the current
middleware/application stacks these days.

Thanks for reading.

-- 
Eric Wong

             reply	other threads:[~2014-05-05  7:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-12 10:04 Eric Wong [this message]
2009-11-14  1:16 ` dealing with client disconnects with TeeInput Eric Wong

Reply instructions:

You may reply publicly 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://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091112100449.GA1929@dcvr.yhbt.net \
    --to=normalperson-rmlxzr9ms24@public.gmane.org \
    --cc=mongrel-unicorn-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \
    --cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhbt.net/unicorn.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).