raindrops RubyGem user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Eric Wong <normalperson@yhbt.net>
To: raindrops@librelist.org
Subject: Re: Raindrops::Middleware::Proxy claims to respond to #body when it does not?
Date: Thu, 17 May 2012 23:18:06 +0000	[thread overview]
Message-ID: <20120517231806.GA16830@dcvr.yhbt.net> (raw)
In-Reply-To: CAO1NZAo6ug83xKRmFYQxwQ4OAuPVE97j_4g-ydums9K3nrRD6Q@mail.gmail.com

Ben Somers <somers.ben@gmail.com> wrote:
> Hi,
> Currently working on the auto-scaler for unicorn that I mentioned on
> that mailing list back in January;


> I'm writing it as an external tool
> that polls against the raindrops middleware to get a crude metric of
> load. (Independently, I'd love your thoughts on whether that's a
> viable/problematic approach; I think I can safely use the active
> count, but details on exactly what those numbers mean would be cool).

active means, well, the active connections userspace knows about
(there's a valid file descriptor/Ruby IO object for it).
queued means the connections are in the kernel queues, and the
userspace app hasn't accept()-ed them, yet.

Unfortunately, I think polling is the least intrusive way, especially on
busy servers (the power usage won't be noticeable if your servers'
already busy).

> In the process, though, I enabled Raindrops::Middleware on a whole
> bunch of servers that weren't running it before, and started getting
> some pretty weird errors on a few of them. Those boxes run a separate
> middleware that writes xml requests to a log file; in the process,
> they call #body on the response object. This works great when they're
> receiving ActionController::Response objects from Rails, but blows up
> on Raindrops::Middleware::Proxy objects.  What I'm seeing is that the
> response passed to my logger middleware is a
> Raindrops::Middleware::Proxy, with an ActionDispatch::Response set as
> its @body. The ActionDispatch::Response responds to #body; the
> Raindrops::Middleware::Proxy does not, since it has its body in a
> plain instance variable without an accessor.
> This tricked my initial workaround, which was to only log the body if
> the response responded to #body, because the Middleware::Proxy winds
> up claiming that it can respond when in fact it cannot. It does so
> because it delegates :respond_to? to its body in almost all cases.

Perhaps you can wrap the Middleware::Proxy response with a Rack::Response
object?  Rack::Response exposes :body as an accessor so it should be
compatible.  I think Rails uses/subclasses Rack::Response, too (but I'm
not remotely up-to-date on Rails internals).

> Clearly the Raindrops::Middleware::Proxy has #respond_to? implemented
> the way it is for a reason, but it seems awfully counterintuitive.

I think I took the hint from Rack::BodyProxy.  The response needs to be
proxied and call the #close method (to decrement the writer count).
Proxying the body is the only way to get a Rack server to call #close
(wrapping #each won't work because #to_path may be used instead)

Without the proxy, raindrops wouldn't be able to instrument (userspace)
time needed to write the response in a Rack-compliant fashion.

> Thoughts/answers? Not necessarily looking for any action here, just
> trying to understand what's going on and why.
> -ben
> PS And yes, I'm totally aware that this logger middleware is dependent
> on an interface not provided for in the Rack specification. I've
> already complained to its author about this, though it probably falls
> on me to correct that.

Yes, it sounds like this logger middleware needs to be fixed :)

> PPS Running on unicorn 4.3.1, raindrops 0.8.1, and rails 3.0.10, if
> that's of any concern.

  reply	other threads:[~2012-05-17 23:18 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-17 19:07 Raindrops::Middleware::Proxy claims to respond to #body when it does not? Ben Somers
2012-05-17 23:18 ` Eric Wong [this message]
2012-05-17 23:37   ` Ben Somers
2012-05-18  0:07     ` 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:

  List information: http://yhbt.net/raindrops/

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

  git send-email \
    --in-reply-to=20120517231806.GA16830@dcvr.yhbt.net \
    --to=normalperson@yhbt.net \
    --cc=raindrops@librelist.org \


* 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


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).