-
Notifications
You must be signed in to change notification settings - Fork 616
Implement limbo resolution listen throttling. #1374
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
Conversation
eab4627
to
9eba6e0
Compare
Binary Size ReportAffected SDKs
Test Logs |
Codecov Report
Continue to review full report at Codecov.
|
9eba6e0
to
6caedce
Compare
6caedce
to
3f0d9ff
Compare
/test device-check-changed |
Coverage ReportAffected SDKs
Test LogsNotesHTML coverage reports can be produced locally with./gradlew <product>:checkCoverage . Report files are located at <product-build-dir>/reports/jacoco/ .
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, though bring in the changelog entry that results from firebase/firebase-js-sdk#2864 before submitting.
/test smoke-tests |
This is a port of firebase/firebase-js-sdk#2790 to Android.
The following description was copied from that PR and pasted here for your convenience:
This change was motivated by the following bug report: firebase/firebase-js-sdk#2683. In summary, the issue was that when a large number of documents went into limbo (in this case 15,000 documents) then this would cause 15,000 document listens, which would result in "resource-exhausted" errors. The client would then back off for a bit but would try the listens again, which would again result in "resource-exhausted" errors. And the cycle would continue. Worst of all, the customer was being billed for all of these reads that had no beneficial effects for the clients.
In order to avoid this situation, this PR modifies the limbo resolution logic to "throttle" the limbo resolutions. It does this by allowing at most 100 concurrent limbo resolutions. Limbo resolutions in excess of this limit are queued up and not started until another limbo resolution completes. This fix should avoid the "resource-exhausted" errors and the infinite read loop.