Re: Raindrops::Middleware::Proxy claims to respond to #body when it does not?

[Eric Wong <normalperson@yhbt.net>]

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;

Cool!

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