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

Async decisions #372

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from
Draft

Async decisions #372

wants to merge 3 commits into from

Conversation

bitcloud
Copy link
Contributor

@bitcloud bitcloud commented Sep 9, 2020

I am using the cassandra API on azure cosmosdb. I was trying to implement a retry policy to handle the request rate limit error. To do that properly I need a way to implement a backoff before the retry.

Currently there is no proper way to handle that with a retry policy. To enable that I made the decision async.

I did not yet implement updated testcases as I wanted to get you in the loop as well and get your input before that.

@bitcloud
Copy link
Contributor Author

bitcloud commented Sep 9, 2020

This is the gist actually using it: https://gist.github.com/bitcloud/7415977bb605dd7b59c3c99f3e0617ee

@bitcloud
Copy link
Contributor Author

hey @jorgebay could you perhaps have a quick look at https://github.com/datastax/nodejs-driver/pull/372/files#diff-86a5418ece89d73a52c91c8fb91288e5R302-R306 as this is the core of the change and tell me if you see any major issues with this approach?
If not, I would continue implementing test.

@jorgebay
Copy link
Contributor

@bitcloud hey! so good to see you here again!

Sorry for the delay in my answer, I didn't have time allotted to this project.

I think the RetryPolicy was conceived as a way to handle w/ timeouts and other issues related to the distributed nature of C*. That's why it's sync: "there was a timeout between coordinator and replicas -> do something". Usually, speculative executions are more into what a user would expect talking to a database (even if its distributed).

That said, I think that a logic for dealing w/ rate limiting does not belong in the driver but in the application code.

@bitcloud
Copy link
Contributor Author

Hey @jorgebay, yes has been a while :)

I thought so that you are going to say something like that ... ;-)

And I would be with you if it not were for the "special feature" in the azure cosmosdb C* api. I would also understand as this is now a datastax driver that it is probably not on any focus. ;-)
But this kind of breaks the streaming feature if used with the azure cosmosdb C* api at the limit of its RU\s. Yes I could just use a simple retry without delay until it works, but honoring the delay seemed to be more elegant.

That said, I know that I could also just implement the pagination api and add the retry logic in the application code, but I thought that could evolve in some kind of exponential backoff reconnection feature as well where you want to retry with a little delay if you are perhaps on a remote connection.

True, the nature of C* is probably not in delaying anything, but being able to doesn't hurt pretty much either, right?

Also it seems to be possible to do something like that in the Java driver as seen in the source of inspiration ;-)
https://github.com/Azure-Samples/azure-cosmos-cassandra-java-retry-sample-v4/blob/master/java-examples/src/test/java/com/microsoft/azure/cosmos/cassandra/CosmosRetryPolicy.java

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