This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-26
Channels
- # 100-days-of-code (3)
- # announcements (2)
- # beginners (237)
- # bitcoin (2)
- # boot (5)
- # cider (15)
- # cljs-dev (9)
- # cljsrn (6)
- # clojure (75)
- # clojure-estonia (1)
- # clojure-italy (8)
- # clojure-losangeles (1)
- # clojure-nl (1)
- # clojure-spec (68)
- # clojure-uk (80)
- # clojurescript (89)
- # cursive (31)
- # datomic (22)
- # emacs (2)
- # events (3)
- # figwheel-main (184)
- # fulcro (28)
- # graphql (1)
- # hyperfiddle (2)
- # jobs (1)
- # jobs-discuss (64)
- # luminus (5)
- # off-topic (16)
- # om (2)
- # onyx (1)
- # pedestal (12)
- # portkey (1)
- # re-frame (13)
- # reagent (56)
- # reitit (13)
- # ring-swagger (13)
- # shadow-cljs (145)
- # slack-help (2)
- # specter (6)
maybe there aren’t that many in circulation 🙂
maybe they should be listed in http://pedestal.io/community/index?
How are people using async-interceptors? What use cases? I’ve yet to use any and I’m curious if any parts of my system could be improved through their use.
@dadair for long running operations. When these are io bound prefer going async via thread
instead of a go
block. So take integrating with a 3rd party service as an example that has a high response time. You don’t want to block your main request processing threads with this work. Integrate with this service in an interceptor that goes async via thread
and return a channel as the context. At some point that interceptor will complete and push an updated context, presumably with some information it collected from the service, to the channel. Processing will continue. Keep in mind that all downstream processing once you go async happens on a thread from the go
thread pool.
great thanks @ddeaguiar
how is backpressure handled in the thread
case? how is it handled in the go
case? with thread
- 100req/sec coming in and 1 thread taking 1sec to complete, there will be soon thousands of threads causing the system to crash?
Pedestal just provides a mechanism for going async. The situation you described by @ikitommi, is possible. So I suppose the answer is more nuanced. Leverage timeouts to avoid waiting an unreasonable amount of time (this is app specific). Depending on the service you are implementing you may need to layer on some form of back pressure to avoid running of threads.