negative timeout in Rainbows::Fiber::Base
Lin Jen-Shin (godfat)
godfat at godfat.org
Tue Dec 18 11:09:51 UTC 2012
On Sat, Sep 29, 2012 at 3:24 AM, Eric Wong <normalperson at yhbt.net> wrote:
> Eric Wong <normalperson at yhbt.net> wrote:
>> So the _actual_ Content-Length that's sent is zero?
>> Rainbows! should drop a connection if an exception is raised while
>> sending the response body, perhaps the heroku router is confused
>> by that?
> Instead of trying "keepalive_timeout 0", you can also try using the
> following middleware. This only works for Content-Length responses
> (which seems to be your case)
> Of course, like all middleware, this makes your stack deeper, so
> maybe it's not good, either...
> Furthermore, this code is totally untested, it may not even compile,
> but I hope you get the idea and fix trivial errors :)
Thank you again for the helps. Since the conference (http://rubyconf.tw/2012)
had ended, I got much more time to work with this now.
I didn't try this middleware because now I feel it might be the problem
in their application, given that it used a ton of gems which might have
some thread-safety issues. On the other hand, the person who asked
me about this telling me that it's fine to run Rainbows! with EventMachine,
but not with ThreadPool. So it is very likely that it's their issues.
As for the issue on my own last time, since it only happened on an
application which we no longer run, and Rainbows! (Zbatery) runs
totally fine on our true production side, I would guess it's a Heroku
issue at that time and it might have been fixed already?
As a result, I want to ignore this issue from now on, and move forward.
I'll send a patch which contains the concurrency models we use on the
production site later in a new thread. Also I might start trying to implement
a new concurrency model based on celluloid-io which I believe the API
would be similar to cool.io, thus might not be hard to implement.
Hope we could get there soon :)
More information about the rainbows-talk