Asynchronous Requests and Stick Middleware Broken

[James Cook]

When using an asynchronous request in Stick/Ringo, we create an AsyncResponse object and return it from the Application handler. After some period of time, the resulting output to the caller is written to the AsyncResponse and the connection is closed. At this time, one would want the middleware stack to unwind, and each middleware has a chance to handle the response object. 

Unfortunately, the middleware is unwound when the AsyncResponse object is returned. Even though the servlet response was waiting for the async functions, stick invokes the middleware immediately, and therefore the middleware has no affect.

This means that any middleware that deals with the response (gzip, cors, csrf, error, etag, etc.) is entirely broken for async handlers. My hunch is that the design change would be also hard to implement because middleware exists between the app and the connector, and the connector handles the async request logic.

[James Cook]

Perhaps it will be possible to use this approach to buffer a response, then some kind of alternate pipeline to invoke middleware on the buffered response? Somehow, the middleware stack would have to be bypassed (or deferred) when connector.js receives an AsyncResponse.

http://stackoverflow.com/questions/24746476/how-to-create-multiple-asynchronous-java-filters

[Simon Oberhammer]

i've only used async responses in the form of eventsources and those didn't need stick middleware.

as you say, changing the design of middleware to fit async response logic isn't trivial. please do tell if you see a feasible approach. in the long run it would be nice if ringo could fully support both, sync and async responses.

 simon