Support for Rack hijack specification

[imanel]

Together with Rack 1.5.0 new specification was added: hijack. Implementing this specification will make creating streaming applications much easier. Is there any plan to add this functionality to Thin in near future?

[macournoyer]

Yes, I hope to. Not sure when I'll have time. When I do it'll be in v2 branch.

[SamSaffron]

@macournoyer it seems pretty simple, api is quite limited, raggi@4acc072

[macournoyer]

The problem with this spec is that it requires pulling the socket out of the event loop which Thin is built around. Some people might not care. But that's not something I want to encourage.

I prefer waiting to see some real use cases for this until it is implemented.

[SamSaffron]

@macournoyer

I feel you, its an awkward api, the thing I dislike most about it is that it is unspecified how to return a socket back the the webserver, so the "nonsense" recommendation is to add a connection close, which makes it horrible for long polling.

That said, it is now implemented in unicorn and passenger, this will allow me to port https://github.com/discourse/discourse/blob/master/vendor/gems/message_bus/spec/lib/middleware_spec.rb to then new API allowing me to give message bus support for the other 2 big player.

I would prefer to only implement one API, that way I can use a threadpool if EM is not around or just pass callbacks back in to EM if it is.

Nothing about the API dictates that I have pull it out of the event loop, I can still easily enough inject it back in.

If the socket had an extra method. #return_to_webserver it would be a direct replacement for throw :async allowing me to maintain less code.

For Discourse our mission it to make Ruby as easy to get out there as PHP is, one key thing here would be to work on multiple web servers. We are super tied to thin (and event machine) now due to rack never ratifying a hijack or async api. At least we have something workable, albeit crazy, to work with now.

[macournoyer]

In a thread based server you could just use a blocking call while waiting for new messages, eg.:

def poll
  Thread.pass until m = message_bus.pop
  render json: m
end

Although Unicorn is not thread based, documentation mention it's safe to use Threads in your app. I think that's the approach you should take instead of playing w/ the socket.

[SamSaffron]

@macournoyer I think I would still have to hijack the socket to get it to work in passenger or unicorn (so they don't run out of request processes) - I am pretty sure "free" passenger is one rack thread per process and same for unicorn. Rainbows should have this built-in and for puma the thread.pass trick can work.