I need some help to understand how the threads are managed by Workers.
We are thinking of using Temporal to orchestrate several microservices. Some of these microservices take a few seconds to respond. These microservice calls will be executed in Activities. So the Worker threads will be blocked till the response is returned.
Will not that create problems if we are going to execute thousands of such Activities and all of the threads are blocked to receive the responses from HTTP endpoints? Please let me know if my understanding is incorrect.
Do we get any benefit if we use an async HTTP client?
Do we need to adjust the Worker threadpool based on the type of Activities?
Yes, if you execute the large number of activities in parallel synchronously you can run out of threads. So using an asynchronous activity implementation with Async HTTP client would help.
Use Activity.doNotCompleteOnReturn to support an asynchronous activity implementation. Here is the relevant sample.
But, I am not sure if it is ok to return Futures from an Activity method. Also, as per the documentation, we should use Promise instead of Future. Is there any sample Activity implementation that uses async HTTP client?
It will be good to know how the threads are managed by Workers. Will it have its dedicated thread pool to execute the Activities? Can I specify a separate thread pool for executing Activities that are long-running and blocking in nature (for example, if we choose to use the sync HTTP client)?