Skip to content

Conversation

@blcksrx
Copy link

@blcksrx blcksrx commented Oct 29, 2025

Implement cachePolicy that users can select the policy between EXPIRE_AFTER_WRITE and EXPIRE_AFTER_ACCESS
#14417

@blcksrx blcksrx force-pushed the hossein/cache_strategy branch 2 times, most recently from 18596d0 to e315119 Compare October 29, 2025 15:37
Signed-off-by: Hossein Torabi <[email protected]>
@blcksrx blcksrx force-pushed the hossein/cache_strategy branch from e315119 to e2bbabf Compare October 29, 2025 15:44
Copy link
Collaborator

@gaborkaszab gaborkaszab left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the contribution @blcksrx !
Just thinking out loud but I'm wondering if this is something that requires configurability or if there is any benefit to keep the expireAfterAccess functionality instead of simply switching to expireAfterWrite without any new configs. Let's see what others say.

old: "method org.apache.iceberg.orc.ORC.WriteBuilder org.apache.iceberg.orc.ORC.WriteBuilder::config(java.lang.String,\
\ java.lang.String)"
justification: "Removing deprecations for 1.2.0"
"1.10.0":
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think these changes are relevant for this PR. Would you mind taking a look?


private final Catalog catalog;
private final boolean caseSensitive;
private final String cachePolicy;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: cacheExpirationPolicy?

* <li>EXPIRE_AFTER_WRITE - cache entries are evicted frequently after cache write
* </ul>
*/
public static final String CACHE_POLICY = "cache.strategy";
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: CACHE_EXPIRATION_POLICY, "cache.expiration-policy"

*/
public static final String CACHE_POLICY = "cache.strategy";

public static final List<String> CACHE_POLICY_VALUES =
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could be an enum

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding being enum at first glance, I went for enum but I saw there is no support for Enums in the PropertyUtils. that's why I have sticked with the String

Caffeine<TableIdentifier, Table> cacheBuilder =
Caffeine.newBuilder()
.softValues()
.removalListener(new MetadataTableInvalidatingRemovalListener())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason moving these out from the if below? Ticker is only relevant there. I also wouldn't add removalListener, nor executor here

cacheBuilder =
cacheBuilder.expireAfterAccess(Duration.ofMillis(expirationIntervalMillis));
break;
default:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't be needed if policy was an enum

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, also it needs a switch case, right?

public void testTableWithMetadataTableName() throws Exception {
TestableCachingCatalog catalog =
TestableCachingCatalog.wrap(hadoopCatalog(), EXPIRATION_TTL, ticker);
TestableCachingCatalog.wrap(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we have a constructor with the old signature that defaults to the default policy? We could get away not changing these tests then.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I needed to write a test case for it, thats why I have added that.

@blcksrx
Copy link
Author

blcksrx commented Oct 30, 2025

Thank you for the contribution @blcksrx ! Just thinking out loud but I'm wondering if this is something that requires configurability or if there is any benefit to keep the expireAfterAccess functionality instead of simply switching to expireAfterWrite without any new configs. Let's see what others say.

Thank you very much. well my intention was not change the existing cache strategy, thats why I made it like that.
Also, I made some comments in your replies. If I could have answer for them. I'd be able to adjust my PR.
Thanks a lot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants