search

bankiprudhvi / google-api-java-client

Automatically exported from code.google.com/p/google-api-java-client
0 stars 2 forks source link

Exponential backoff for access token requests failing due to rate limits #648

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
copied from: 
https://code.google.com/p/google-oauth-java-client/issues/detail?id=57

Version of google-oauth-java-client (e.g. 1.5.0-beta)?
1.12.0-beta

Java environment (e.g. Java 6, Android 2.3, App Engine)?
Java 6, presumably non-AppEngine unless you're not using the AppEngine robot 
credentials.

Describe the problem.
1. Share the refresh token with 10+ machines.
2. Perform an authenticated API request across the same machines simultaneously.
Expected: Eventual success.
Actual: Access denied error.

How would you expect it to be fixed?
https://code.google.com/p/google-oauth-java-client/source/browse/google-oauth-cl
ient/src/main/java/com/google/api/client/auth/oauth2/TokenRequest.java#303

http://code.google.com/p/gsutil/source/browse/trunk/src/oauth2_plugin/oauth2_cli
ent.py#343

The problem is that if you have many machines hitting the token endpoint for 
the same refresh token, you will hit the rate limit and further requests will 
yield 403 without any computer-readable indication that you've hit a rate limit 
(there is human-readable HTML in the response that so indicates). We need to 
treat 403s as if they were a 429 (http://tools.ietf.org/html/rfc6585) and, 
without a Retry-After field, just use exponential backoff to try and get a 
refresh token. (If a Retry-After field were available, use it to establish a 
baseline for adding extra delay.)

This will not fix the underlying problem, but it will amelioriate it, and 
slowly machines will be able to start work.

In this case, we cannot expect that the response will contain JSON, so we'll 
have to fall back on raw HTTP code handling.

My comment:

Problem is we have no good way yet of knowing that a 403 is recoverable.  
Another potential source of 403 for Google APIs is if the API hasn't been 
enabled in the APIs Console.  So we need a reliable way of detecting that.  One 
possibility is to read the human-readable HTML, but that seems prone to fail in 
the future.  So at this point I don't have a concrete proposal yet, and 
therefore I'll keep it as Low priority, but I'll keep it open until we do.

Original issue reported on code.google.com by yan...@google.com on 2 Nov 2012 at 12:17