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 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 returned ASAP, which means blocking I/O typically > isn't much of a bottleneck. > > > > However, since Ring 1.2, all of the standard middleware has also been > available to use asynchronously, in order to support frameworks like > Pedestal. So it's certainly possible to use Ring in an async environment, > at least with the core Ring libs. > > > > Although HTTP Kit doesn't use core.async channels itself, the async > protocol used isn't complex. You should be able to hook up core.async/take! > to http-kit/send!. Something like: > > > > (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! http-ch resp) > (httpkit/close http-ch)))))) > > That’s what I wanted to do, but then I saw the warning on http-kit’s > website at http://http-kit.org/server.html#channel , which states: > > Data is sent directly to the client, NO RING MIDDLEWARE IS APPLIED. > > … which leads me to believe that the send! API just totally sidesteps any > middleware, and it’s not so much up to the middleware whether or not it > supports asynchronous operation. Unless of course it actually works fine, > and that’s simply some stale documentation? > > > That said, I'd be wary about having HTTP clients wait around on the > server. If it's just a few seconds, that seems reasonable, but any longer > and you should consider redirecting to a "job" resource instead. > > Yeah, I’ve been considering that. Looking at the distribution of response > times right now, > 5-10s is a small, but non-negligible part of the > responses. However, the point of this software is being able to give third > parties capabilities (in the object-capability sense), so typically some of > the requests involve secrets the caller doesn’t get to know about (like API > credentials). As a result, I’m trying to be hyper-conservative in terms of > stuff that can leak information. I’ll have to think more about that one :-) > > hth > lvh > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
