cacheDuration impact of setting this to 100ms

We recently experienced issues with the cf-java-client where the cache duration was set to indefinite by default as detailed in the issue https://github.com/cloudfoundry/cf-java-client/issues/749. However, this happened in an able that had otherwise been stable but had to refresh its access token. Upon attempting to refresh the application received a connection timeout or a sporadic 404 from the uaa server (likely during a repave of the foundation or for some unknown reason). This resulted in some requests from the same application caching the 404 or the connection timeout which rendered some operations inoperable. We have debated setting the context.cacheDuration equal to 100 ms or 1 ms to avoid this possibility but was concerned with what the potential impact this would have? We also would like to lobby for a completely different approach to be taken for caching these stable payloads such as adding exception handling that will retry in the case of IOexceptions instead of caching the error condition indefinitely.

Start by reading the context.cacheDuration behavior described here and the related cf-java-client issue 749, then trace how cached 404 responses and connection timeouts are handled during UAA access-token refreshes. Done means an agreed caching or retry design prevents transient errors from being cached indefinitely, with its impact on 100 ms and 1 ms durations established.