JingsongLi commented on code in PR #9528:
URL: https://github.com/apache/paimon/pull/9528#discussion_r3909608616
##########
paimon-common/src/main/java/org/apache/paimon/rest/RESTTokenFileIO.java:
##########
@@ -82,6 +82,23 @@ public class RESTTokenFileIO implements FileIO {
private static final Logger LOG =
LoggerFactory.getLogger(RESTTokenFileIO.class);
+ /** Sets the maximum number of cached FileIO instances. */
+ public static void setFileIOCacheMaximumSize(long maximumSize) {
+ FILE_IO_CACHE
+ .policy()
+ .eviction()
+ .orElseThrow(IllegalStateException::new)
+ .setMaximum(maximumSize);
Review Comment:
[P2] Do not accept a zero cache size with the current ownership model
The new test explicitly makes `0` a supported value, but this cache owns its
values: its removal listener closes every evicted `FileIO`. With a Caffeine
maximum of zero, `fileIO()` creates an instance, puts it into `FILE_IO_CACHE`,
and it is immediately eligible for SIZE eviction/close even though the method
then returns that same instance to the current operation. An application using
the conventional `0 = disable caching` setting can therefore get a closed
FileIO during `newInputStream`, `newOutputStream`, etc., reproducing the
premature-close failure this change is intended to mitigate.
Please either require `maximumSize > 0`, or implement an explicit no-cache
path whose FileIO lifetime extends through the operation instead of inserting
it into this owning cache.
--
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]
