Patterns on how to use Pool

[JeroenSoeters]

I was exploring the use of the Pool actor to create a worker pool for throttling requests to an external service. The pool size would effectively be my rate limit, and I intended for the actors exercising the pool to retry submitting requests when the pool is full, until a worker becomes available. However, I realized that the pool doesn't provide any feedback on whether it is full or not. The pool would forward the calls I would issue to an actor, but forward itself doesn't have a return value. This means that, from a caller, you will always receive a timeout error, whether the pool is full or the actor handling the message crashes. Afaik there is no way to distinguish between the two. Am I missing something or is this not an intended use case for the Pool actor?

[halturin]

Yes, act.Pool ignores messages if none of the workers are available. It just logs the error message.

The reason it works this way is that a response only makes sense in the context of a request, and synchronous messaging is merely an abstraction over asynchronous messaging.

As you may have noticed, act.Pool doesn't process incoming messages to distinguish their types - it simply forwards them to the workers.

Sure, this could be improved. The main challenge is ensuring consistent behavior for both sync and async messages sent to act.Pool in such cases - how should act.Pool behave for messages sent using gen.Process.Send or for requests made using gen.Process.Call

[JeroenSoeters]

Yea this makes sense. Let me think a bit more about this, you're right this only works for synchronous calls unless clients have some standardized way of telling the rate limiter whether they're busy or free.