Fork me on GitHub
#pedestal
<
2018-09-26
>
stathissideris07:09:33

maybe there aren’t that many in circulation 🙂

ddeaguiar14:09:27

merged. Thanks!

orestis10:09:37

So cool. I never knew all those things. Thanks!

dadair18:09:11

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.

ddeaguiar19:09:38

@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.

ikitommi19:09:35

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?

ddeaguiar19:09:31

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.

ddeaguiar19:09:18

Taking additional precautions, like leveraging circuit breakers, would be a good idea as well