> @@ -51,9 +56,17 @@ protected RetryOnRenew(LoadingCache<Credentials, Access> > authenticationResponseC > this.authenticationResponseCache = authenticationResponseCache; > } > > + /* > + * The reason retries need to be tracked is that it is possible that a > token can be expired at any time. > + * The reason we track by request is that only some requests might return > a 401 (such as temporary URLs). > + * However consistent failures of the magnitude this code tracks should > indicate a problem. > + */ > + private static Cache<HttpCommand, Integer> retryCountMap = > CacheBuilder.newBuilder() > + > .expireAfterWrite(5, TimeUnit.MINUTES)
5 min - this is to prevent fake positives from having these records around a long time (tokens expire). Configurable - I am of the opinion that edge cases with little user exposure should not be configurable. For example - configuring retries on 500 - yes, definitely. Configuring the heuristics for re-authentication, I'm not so sure. Thoughts? HttpRequest vs HttpCommand - yes that is correct. I don't see the reason to use the lower level of abstraction in here though, the code already used the command one. --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds/pull/104/files#r5665510
