Handle read_timeout for queries executed within EventMachine #971
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello, I'm not sure if this is the best approach to handle a
read_timeout
when a query is being run within an EventMachine reactor loop, but I wanted to give it a try and pick your brain on the topic :)The
read_timeout
option is only used when a query is executed synchronously, so it will be completely ignored forEM
clients.mysql2/ext/mysql2/client.c
Lines 782 to 792 in b3fe727
In order to expose a similar behaviour I've introduced a Deferrable Timeout which will raise a
Mysql2::EM::ReadTimeout
.In case of a read timeout from the normal non-evented client, a
Mysql::Error
is raised, but I am not sure it would be ok to raise that exception in this case.I also understand that a change like this one would break compatibility. Maybe there is a better way to expose this timeout logic to the client code. On the other hand it is also a bit counter intuitive to have a
read_timeout
option that doesn't do anything when the client is evented :)Please let me know what you think about it.
Have a nice day!