Hi James,
Thanks for your response! Replies inline.
On 02 Sep 2014, at 18:53, James Reeves ja...@booleanknot.com wrote:
Ring uses blocking I/O by default, because that's often sufficient for most
web servers, and is generally easier to reason about. HTTP works best when
the response is
Pedestal pedestal-service handles requests asynchronously by extending the
ring standard with Interceptors, sort of a state machine queue version the
wrapped handlers of ring.
/Linus
Den 3 sep 2014 10:35 skrev Laurens Van Houtven _...@lvh.io:
Hi James,
Thanks for your response! Replies
Yet another: I'm using a servlet implementation, that can be deployed in
any servlet container supporting servlet api 3.0 (with async)
https://github.com/webnf/webnf/tree/master/async-servlet
It allows to return a function instead of a regular ring response, that
will get an async context to
On 3 September 2014 09:35, Laurens Van Houtven _...@lvh.io wrote:
(defn handler [req]
(httpkit/with-channel req http-ch
(let [resp-ch (async-handler! req)]
(httpkit/on-close (fn [_] (a/close! resp-ch)))
(a/take! resp-ch (fn [resp] (httpkit/send!
Hi,
I'm writing a pretty simple HTTPS API that, when you make a request to it,
it makes a bunch of requests on your behalf, and eventually reports success
or failure. Because it makes many requests with a bunch of interaction
between them, I'd really like to use core.async. Internally (that
Ring uses blocking I/O by default, because that's often sufficient for most
web servers, and is generally easier to reason about. HTTP works best when
the response is returned ASAP, which means blocking I/O typically isn't
much of a bottleneck.
However, since Ring 1.2, all of the standard
