synchronous controllers taking 6 seconds in Eventmachine config

synchronous controllers taking 6 seconds in Eventmachine config

[Christoph Sturm]

hello rainbows friends!

we use rainbows in eventmachine mode, and it seems there's a bug in handling of synchronous responses.

this controller takes 6 seconds:

def call(env)
      Rack::Response.new.finish
end

this only occurs when i dont set a content length, for example this controller returns immedately:

def call
   [200, {'Content-Length' => 2}, ['OK']]
end

it also doesnt seem to be eventmachine specific, if i remove the use  :Eventmachine it also happens.

-chris
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: synchronous controllers taking 6 seconds in Eventmachine config

[Eric Wong]

Christoph Sturm <me-Nf+wZpSdgweeYOMve9Zru9BPR1lH4CV8@public.gmane.org> wrote:
> hello rainbows friends!
> 
> we use rainbows in eventmachine mode, and it seems there's a bug in
> handling of synchronous responses.
> 
> this controller takes 6 seconds:
> 
> def call(env)
>       Rack::Response.new.finish
> end
> 
> this only occurs when i dont set a content length, for example this
> controller returns immedately:
> 
> def call
>    [200, {'Content-Length' => 2}, ['OK']]
> end
> 
> it also doesnt seem to be eventmachine specific, if i remove the use
> :Eventmachine it also happens.

Hi Chris, this is because the client doesn't know when to stop
reading the connection otherwise, and waits until the keepalive
timeout (5 seconds or so by default).

"Content-Length" (or "Transfer-Encoding") is required by the Rack spec,
so you need to include it in your app (or use
Rack::ContentLength and/or Rack::Chunked middlewares).

Starting with Rainbows! 0.97.0, you can set "keepalive_timeout 0" in
your Rainbows! config block to disable keepalive across all concurrency
models, which lets you violate the Rack spec and get immediate
responses.

-- 
Eric Wong
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: synchronous controllers taking 6 seconds in Eventmachine config

[James Tucker]

Eric, you don't do actual keepalive do you, or am i thinking of unicorn?

If the request is sync, then you can close connection after body.each returns, else you need to use the deferrable api callback in deferrable bodies wiht the async api.
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: synchronous controllers taking 6 seconds in Eventmachine config

[Eric Wong]

James Tucker <jftucker-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Eric, you don't do actual keepalive do you, or am i thinking of
> unicorn?

Rainbows! has had keepalive and pipelining since the earliest releases
for simple GET/HEAD requests.  At least there are integration tests
using curl that do keepalive, so it should work :)  Keepalive for
proxying sockets/pipes (without async.callback) has improved with recent
releases, too.

Rainbows! will support keepalive for all other body-less requests, too,
and _maybe_ optionally supporting keepalive PUT/POST requests with a
body.  For requests with a body, the app must consume the entire body
(which intentionally does not happen for "synchronous" concurrency
models).

Unicorn doesn't do keepalive since nginx doesn't do keepalive to
backends, yet.   That will change if nginx (or another comparable
frontend emerges) supports keepalive to the backends.

> If the request is sync, then you can close connection after body.each
> returns, else you need to use the deferrable api callback in
> deferrable bodies wiht the async api.

The EM deferrable doesn't do keepalive right now, and may not ever
because (I assume) it's used for long-polling and such.

Setting "keepalive_timeout 0" for any app doing long-polling/Comet stuff
is probably a good idea anyways, the client can't reliably know which
requests take a long time.

-- 
Eric Wong
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying

Re: synchronous controllers taking 6 seconds in Eventmachine config

[Eric Wong]

Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote:
> James Tucker <jftucker-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > If the request is sync, then you can close connection after body.each
> > returns, else you need to use the deferrable api callback in
> > deferrable bodies wiht the async api.
> 
> The EM deferrable doesn't do keepalive right now, and may not ever
> because (I assume) it's used for long-polling and such.

Would supporting keepalive for people using "async.callback" help some
folks?   As of 0.97.0, it's possible to disable keepalive entirely
across all concurrency models, so perhaps allowing the app to specify
the "Connection" header is helpful, too...

-- 
Eric Wong
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying