This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-03-27
Channels
- # aleph (5)
- # announcements (18)
- # beginners (200)
- # cider (25)
- # cljdoc (4)
- # cljsrn (3)
- # clojure (90)
- # clojure-europe (3)
- # clojure-finland (5)
- # clojure-france (1)
- # clojure-houston (1)
- # clojure-italy (8)
- # clojure-nl (15)
- # clojure-spec (24)
- # clojure-uk (20)
- # clojurescript (199)
- # core-async (2)
- # cursive (45)
- # data-science (14)
- # datomic (33)
- # duct (13)
- # fulcro (4)
- # graphql (3)
- # kaocha (9)
- # leiningen (24)
- # nrepl (16)
- # off-topic (105)
- # pathom (15)
- # pedestal (28)
- # re-frame (1)
- # reagent (14)
- # shadow-cljs (28)
- # spacemacs (8)
- # tools-deps (8)
- # vim (4)
@UAEH11THP You may want to ask @seancorfield
(who is not in this channel) if you have questions about instrumenting NewRelic.
Hi! When sending an HTTP request with aleph, I prefer to wrap http/get
into a future. This is to catch some possible exceptions related to a malformed URL, for example. One of my teammates noticed that such a structure consumes two threads that probably leads to a bottleneck. It it really so?
clojure
(->
(d/future
(http/get url))
(d/chain
(fn [response]
(let [{:keys [headers]} response
content-length (get headers "content-length")]
...)))
(d/catch
(fn [^Exception e]
...)))
@igrishaev http/get
is non-blocking, while d/future
uses a thread, so isn't a good wrapper for http/get
. if you are seeing exceptions before the first callback of http/get
, what I've done in similar circumstances is use a macro which wraps its body in a d/catch
and a try ... catch
and ensures you always get a Deferred
result
I'm afk atm, I'll try and post some code tomorrow if that would be helpful