From: Eric Wong <firstname.lastname@example.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)
Ben Somers <email@example.com> wrote:
> 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'
> 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.
> 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.
next prev parent 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
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: https://yhbt.net/raindrops/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).