Closed QuinnWilton closed 4 years ago
@QuinnWilton fetching the queue length would be tough as that would be a request to NimblePool server. One alternative is for us to keep a counter or a ETS table, but that may be out of scope for the library. Another idea is for us to provide a handle_enqueue
/handle_dequeue
callbacks, which will be invoked whenever requests come-in and come-out. Then you can increment and decrement the counter as you wish. However, this callback won't be invoked per worker, but for the whole pool. So we would also need to make init_pool
return {:ok, pool_state}
and have the pool_state
be the one received and returned by the queue/dequeue callbacks. WDYT?
Thank you for the detailed and quick response @josevalim!
It being hard to access makes a ton of sense, and I understand the apprehension to expand scope by including an ETS table in the library too. I do like the idea of providing those callbacks. I think that they would give me the functionality I care about, without making the library responsible for too many things.
@sneako, do you think that would be a helpful path to go down to get smarter pool balancing strategies implemented in Finch
?
Yeah, I think these callbacks should be enough for us!
Please do send a PR and if there is anything I can help with please let me know!
I was thinking about how to implement a "least loaded" pooling strategy for https://github.com/keathley/finch/issues/8, and didn't see a way of grabbing the queue length. Is that something that would be worth adding to
nimble_pool
?