cacheDuration impact of setting this to 100ms

[xyloman]

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.

[stwomack]

Bump?

[dmikusa]

For what it's worth, I believe this comment summarizes the concerns when adjusting the cache durations well: https://github.com/cloudfoundry/cf-java-client/issues/749#issuecomment-340617201

Revisiting the way that the caches are used is something that we can do, but it's not a priority at this point in time given that there are cache controls that can be adjusted to get reasonable behavior in a lot of cases.

I will leave this issue open. If it of interest to whoever is reading this, please 👍 this post & share your use case. Thanks

[kvmw]

We had a similar report from a SCS customer. SCS broker was not able to talk to UAA with connection timeout issue. Since there is not cache duration configured in SCS broker, the only way to solve the issue was to restage/restart the broker application which is not what you want to do in prod env.