From: Ben Somers <firstname.lastname@example.org> To: email@example.com Subject: Raindrops::Middleware::Proxy claims to respond to #body when it does not? Date: Thu, 17 May 2012 12:07:42 -0700 Message-ID: <CAO1NZAo6ug83xKRmFYQxwQ4OAuPVE97j_4g-ydums9K3nrRD6Q@mail.gmail.com> (raw) In-Reply-To: <CAO1NZAo6ug83xKRmFYQxwQ4OAuPVE97j_4g-ydums9K3nrRD6Q@mail.gmail.com> 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). 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. Clearly the Raindrops::Middleware::Proxy has #respond_to? implemented the way it is for a reason, but it seems awfully counterintuitive. 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. PPS Running on unicorn 4.3.1, raindrops 0.8.1, and rails 3.0.10, if that's of any concern.
next parent reply index Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-05-17 19:07 Ben Somers [this message] 2012-05-17 23:18 ` Eric Wong 2012-05-17 23:37 ` Ben Somers 2012-05-18 0:07 ` Eric Wong
Reply instructions: You may reply publically 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://bogomips.org/raindrops/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAO1NZAo6ug83xKRmFYQxwQ4OAuPVE97j_4g-ydums9K3nrRD6Q@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ /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
raindrops RubyGem user+dev discussion/patches/pulls/bugs/help Archives are clonable: git clone --mirror https://bogomips.org/raindrops-public git clone --mirror http://ou63pmih66umazou.onion/raindrops-public Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.lang.ruby.raindrops nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.raindrops note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox