-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
returning worker to pool too early? #1
Comments
Sorry I didnt notice your message... And thanks for your message :-) At first, I am not measuring actual speed. //////////////// I think that yes, the method is usually right. But I read source code of eredis and I notice that eredis dont block receive next request, until returning result. And I read document for redis, and I got to know that redis suppot pipelining server-client protocol. I think... [checkout -> eredis:q(...) -> checkin] will be repealed pipelining protocol. And poolboy not necessary for eredis....? No. redis can receive request non-blocking but order of response is same as request order. And I readed source code of poolboy. Poolboy using queue:in and queue:out for management of process pool. queue:in add value to rear of queue, and queue:out removes from front of queue. So I thought that the same process did not receive a request repeatedly. Now, I think [checkout -> checkin -> eredis:q(...)] logick is best method for using poolboy for eredis utilize pipelining. Thank you :-) |
@hiroeorz It's true, you should never checkin the worker before you're done working with it. I'm unfamiliar with how eredis works, but you shouldn't rely on an internal implementation detail of Poolboy as that may change any day. I even recommend using the new |
I understand. I changed to using poolboy:transaction/2. Thank you :-) |
Hi,
I was just reading through your code (planning to use poolboy for a connection pool myself), when I noticed something weird in eredis_pool:q/3:
q(PoolName, Command, Timeout) ->
Worker = poolboy:checkout(PoolName),
poolboy:checkin(PoolName, Worker),
Reply = eredis:q(Worker, Command, Timeout),
Reply.
shouldn't the poolboy:checkin.. really happen after the Worker has done its eredis:q... request? like so:
q(PoolName, Command, Timeout) ->
Worker = poolboy:checkout(PoolName),
Reply = eredis:q(Worker, Command, Timeout),
poolboy:checkin(PoolName, Worker),
Reply.
otherwise the worker immediately becomes available to other concurrent clients, even before it is done with the request, no?
I am not really planning to use redis at the moment, so ignore / delete at your leisure, but since I already spotted it, I figured I may as well drop you a note.
Fabian
The text was updated successfully, but these errors were encountered: