Is async supported? about fishwife HOT 6 CLOSED

That used to be a flush, but then Jetty 9 wants a close of each response, so its entirely possible I broke it for Jetty 9 support. Before that, and as commented in #7, the only test for this failed intermediately, apparently due to some thread timing issue.

To resurrect this, I think I saw that Jetty later added more "standard" support for async? Servlets specified? Does rack now define a more standard interface for ruby as well?

I'm receptive to pull requests re-working the feature with above considered and reliable tests. Easier to merge if its clear in the code that changes don't effect the common case, non-async path.

from fishwife.

If I've understood things correctly Servlet API 3.0 added support for async request handling, which Jetty 8 implemented. Jetty has of course had its own async processing API since a long time.

I tried finding documentation on how async.callback was supposed to work, but it seems like it's an effort that has been abandoned. The replacement is rack.hijack, which is more low level (see "Hijacking" in the Rack spec). Instead of providing a callback that can take a response at a later time you signal that you want to take control over the response IO completely. You get an IO-like object that you can do whatever you want with. The benefit over async.callback is that it's in the spec, but the downside is that it's not portable, by design (don't you love it when a spec says "There is a deliberate lack of full specification around rack.hijack_io, as semantics will change from server to server").

I think that maybe scrapping the async.callback support completely and instead trying to implement support for rack.hijack would be the way to go for Fishwife. Maybe async.callback can be implemented on top of rack.hijack if you feel it's important to be backwards compatible. I can try to make a stab at it.

I don't know if there is much benefit in using the Servlet API variant of async handling over Jetty's own, but if you think it would be better I can do that too.

from fishwife.

Looking a bit more at the rack.hijack spec I'm not sure if it would be possible to implement the "request" part of the spec (where the server hands off the socket to the application without even sending headers), I don't know if Jetty allows that. The "response" part might be possible though.

from fishwife.

Looks like servlets 3.1 further extends the async support. But the older Jetty continuations interface looks like it continues to be supported, so it might just be a question of what is easier to work with.

There is plenty of jetty release notes referencing async. in 9.3.x and 9.4.x and its also again time for updates to rjack-jetty. I will prioritize those if you start working on this.

Regarding rack, I agree with your analysis. The rack.hijack pseudo-spec seems permissive enough, with the "response" pattern decoupled from "request." I wonder if there are some useful tests that could be reused, from either rack itself, or maybe Puma?

from fishwife.

I made a first spike to see how things worked: https://github.com/dekellum/fishwife/compare/fishwife-dev...iconara:hijack-support?expand=1

It's tricky to write a proper test that won't take a couple of seconds to run. I've just written a basic test that ensures that the request gets a proper response (and since the request handling happens in a separate thread it kind of proves that it works, but it's by far a great test) – I will have a look at how Puma tests it.

Using Servlet API's async handling was very easy, even easier than Jetty continuations. I don't think there will be any need for the async IO from Servlet 3.1.

I'll try to do some more research on whether or not it's possible to hijack Jetty's output stream before it sends the headers.

from fishwife.

I opened a PR so that your review comments don't get lost.

from fishwife.