retry preparing statements when there is a cassandra error #330
Conversation
| .to receive(:execute) | ||
| .with(->(s){ s.cql == statement}, | ||
| hash_including(:consistency => cequel.default_consistency)) | ||
| .and_raise(Cassandra::Errors::NoHostsAvailable) |
There was a problem hiding this comment.
This was actually supposed to raise Cassandra::Errors::ExecutionError
| context "with a connection error" do | ||
| it "reconnects to cassandra with a new client after no hosts could be reached" do | ||
| allow(cequel.client) | ||
| .to receive(:prepare_statement) |
There was a problem hiding this comment.
the expected receives were supposed to be just prepare
|
It makes completel sense that prepare would fail that way. Thanks for the improvement. |
|
looks like a couple fixes didnt get made before my battery died. I can make those changes later tonight when im back online. |
| sleep(retry_delay) | ||
| retry | ||
| end | ||
| end |
There was a problem hiding this comment.
Could we extract this and the execute retry logic into a retry method that takes a block?
|
dried up the retry code and fixed up the tests with the correct exceptions |
|
Thanks for the improvement! |
|
Anytime! The next thing Ill probably look into is making this gem thread safe as it would be nice to use sidekiq. |
|
Thread safety would be awesome. |
|
Released in 2.0.2 |
I started discovering new Cassandra Errors being propagated up when updating to v2 of this gem. I traced it down to the fact that preparing the statement can raise most of the same errors as the execution. I also thought it was appropriate to switch to catching the errors specified in the docs.
prepare docs
execute docs