From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS6939 64.71.128.0/18 X-Spam-Status: No, score=-1.9 required=3.0 tests=AWL,BAYES_00, MSGID_FROM_MTA_HEADER shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: Eric Wong Newsgroups: gmane.comp.lang.ruby.raindrops.general Subject: Re: Raindrops::Middleware::Proxy claims to respond to #body when it does not? Date: Thu, 17 May 2012 23:18:06 +0000 Message-ID: <20120517231806.GA16830@dcvr.yhbt.net> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1337296700 31252 80.91.229.3 (17 May 2012 23:18:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 17 May 2012 23:18:20 +0000 (UTC) To: raindrops@librelist.org Original-X-From: raindrops@librelist.org Fri May 18 01:18:19 2012 Return-path: Envelope-to: gclrrg-raindrops@m.gmane.org List-Archive: List-Help: List-Id: List-Post: List-Subscribe: List-Unsubscribe: Precedence: list Original-Sender: raindrops@librelist.org Xref: news.gmane.org gmane.comp.lang.ruby.raindrops.general:65 Archived-At: Received: from zedshaw.xen.prgmr.com ([64.71.167.205]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SV9xX-0008TT-1L for gclrrg-raindrops@m.gmane.org; Fri, 18 May 2012 01:18:15 +0200 Received: from zedshaw.xen.prgmr.com (localhost [IPv6:::1]) by zedshaw.xen.prgmr.com (Postfix) with ESMTP id 554EE21DBA3 for ; Thu, 17 May 2012 23:25:48 +0000 (UTC) Ben Somers 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.