I have an async interceptor that returns a channel. For example:

(def my-async-interceptor
  {:enter
   (fn [context]
     (println "start processing")
     (async/go
       (println "inside go block")
       ;; imitate some time consuming process
       (async/<! (async/timeout 10000))
       (assoc context :response {:status  200
                                 :body    "ok"
                                 :headers {}})))})

@kenny the backing threadpool for go is small. I suggest using thread with io-bound operations. Keep in mind that once you go async, the remaining interceptors are processed on a go thread once your async interceptor returns.

@ddeaguiar Do you recommend for handlers that could have lots of longish (~10s) requests pending to simply be "synchronous"? i.e. no go block?

@kenny no, I’d move those off the servlet thread. I typically perform any heavy-lifting/integration in interceptors and limit the final handler to response handling

if you have longish operations, you can use thread instead.

Not sure I totally understand what you mean. In my case my handler sends a message to an external service that processes the request. The handler then takes the response from the external service and constructs a HTTP response. All of that is happening in the final handler in the interceptor chain.

so you can move the integration piece to an interceptor and leave the response processing to the handler

Why would that make a difference?

Just communicating how I normally split up work. Either way, use thread not go

caveat is this

if your handler returns a channel then that channel is expected to return a response body

if an interceptor returns a channel, then that channel is expected to return a context map

I tend to avoid io-bound operations on the serving thread and go blocks

best to keep those free

particularly if integrations take ~10s

Most often they will take a much shorter time 0-2s but sometimes it may take ~10s.

still 2s is a long time

I’d also consider introducing a circuit-breaker

Is that more than a simple timeout?

the pattern is more than that but a timeout is a good start

That may be enough though. It depends on what your needs are

The way it is written now is it waits for a response from the external service for up to 10s, if no response is returned when 10s is hit then an error response is returned.

Depending on what type of system you are building and the traffic you expect, you can end up exhausting your thread pool

if, for example, the system you are integrating with goes down for a long period of time

with a circuit breaker you can detect errors and trip the breaker causing additional requests to fail fast

then you can test some requests to see if the situation has been resolved

and either close the breaker or leave it tripped

Hystrix is commonly used here https://github.com/Netflix/Hystrix/wiki

but there’s a bit of ceremony involved so you’d use something like this if you really need it

If the threadpool gets exhausted, what happens to additional requests that come in?

I suppose you’ll see some form of queueing. You’ll see response times go up.

Hmm. Any idea how easy it'd be to exhaust the thread pool?

If you use go, pretty easy since it’s small (like 8ish threads)

AFAIK, thread is unbounded so you are limited by your system

you can change the pool size for go

It sounds like thread is the right approach here.

I’ve never worked outside of the defaults here

What do you mean?

I’ve never changed the default threadpool size in core.async

but you can http://clojure.github.io/core.async/#clojure.core.async/

go blocks are dispatched over an internal thread pool, which
defaults to 8 threads. The size of this pool can be modified using
the Java system property `clojure.core.async.pool-size`.

Oh. Why would I want to do that over using thread?

Just pointing out it’s possible. I wouldn’t

the heuristic I use for choosing between go and thread are: cpu-bound -> go, io-bound -> thread

That's quite useful! I'll change to thread for IO ops. Thanks.

np!