Skip to content
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

Add configurable response expiration time to Server #1

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

timopohl
Copy link

Hey!
I noticed that in our application, when under load, the server sometimes sends and expires the response for a request faster than the client can look up the response.

These are the calls in a working situation:

1594364792.203118 [0 unix:/tmp/redis.sock] "rpush" "routing" "{\"function_call\":{\"name\":\"some_function\",\"args\":[1]},\"response_queue\":\"routing:rpc:C3QZR3XM\",\"timeout_at\":1594364857}"
1594364792.203384 [0 unix:/tmp/redis.sock] "blpop" "routing:rpc:C3QZR3XM" "5"
1594364792.204651 [0 unix:/tmp/redis.sock] "rpush" "routing:rpc:C3QZR3XM" "{\"return_value\":[9999]}"
1594364792.204665 [0 unix:/tmp/redis.sock] "expire" "routing:rpc:C3QZR3XM" "1"

The first two calls are the client pushing a request and immediately block-popping the response, effectively monitoring the list for the response of the server.
But sometimes this situation shows up:

1594364792.179018 [0 unix:/tmp/redis.sock] "rpush" "testing" "{\"function_call\":{\"name\":\"some_function\",\"args\":[1]},\"response_queue\":\"testing:rpc:8K5VTB6O\",\"timeout_at\":1594364857}"
1594364792.185593 [0 unix:/tmp/redis.sock] "rpush" "testing:rpc:8K5VTB6O" "{\"return_value\":[9999]}"
1594364792.185608 [0 unix:/tmp/redis.sock] "expire" "testing:rpc:8K5VTB6O" "1"
1594364793.600321 [0 unix:/tmp/redis.sock] "blpop" "testing:rpc:8K5VTB6O" "5"
1594364798.878143 [0 unix:/tmp/redis.sock] "lrem" "testing" "0" "{\"function_call\":{\"name\":\"some_function\",\"args\":[1]},\"response_queue\":\"testing:rpc:8K5VTB6O\",\"timeout_at\":1594364857}"

So the client first pushes the request, then the server immediately pushes and expires the response before the client calls the "blpop" command on the message queue. At the point where the client calls the "blpop" command, the response is already expired.

The proposed changes offer a configurable expiration duration for the server responses, giving the client more time to get the response back from redis.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant