anoopvs opened a new issue, #17518: URL: https://github.com/apache/iceberg/issues/17518
### Query engine _No response_ ### Question Description AuthSessionCache currently uses Caffeine's expireAfterAccess(sessionTimeout) for session eviction. https://github.com/apache/iceberg/blob/main/core/src/main/java/org/apache/iceberg/rest/auth/AuthSessionCache.java#L129 My understanding is that an AuthSession is created when the RESTCatalog is initialized and is reused from the cache until it is evicted. Using expireAfterAccess extends the cache lifetime every time the session is accessed. As a result, a frequently used AuthSession may remain in the cache even after its underlying access token has expired. ``` [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-4 << "[\r][\n]" [main] DEBUG org.apache.hc.client5.http.wire - http-outgoing-4 << "{"error":{"code":401,"message":"Invalid or missing auth token","type":"UnauthorizedException"}}" Exception in thread "main" org.apache.iceberg.exceptions.NotAuthorizedException: Not authorized: Invalid or missing auth token ``` Expected behavior It seems that expireAfterWrite(sessionTimeout) would better match the lifecycle of an AuthSession, since the session lifetime is based on when it was created rather than how frequently it is accessed. With expireAfterWrite, the cached session would be recreated after the configured timeout, allowing a new authentication session/token to be established. Question Is the current use of expireAfterAccess intentional? If AuthSession is expected to refresh tokens internally, then expireAfterAccess makes sense. However, if the session does not always refresh expired tokens, would expireAfterWrite be a better eviction policy? I'd appreciate some guidance on whether this is the intended behavior? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
