Conversation
JindoFileIO only appended dlf.access-tracking.extended-info to fs.oss.user.agent.extended, so dls:// requests lost it, and Paimon was identified only through Jindo's call-stack detection, without a version. JindoFileIO now fills fs.oss.user.agent.* and fs.dls.user.agent.* with Paimon's unified User-Agent: Paimon/<version> leads the features, the catalog-wide user-agent.module/features/extended apply unless the fs.<scheme>.user.agent.* key for that part is set, and the access tracking info is appended after the extended part. The version is written into JindoBuildVersions at build time by the templating-maven-plugin, so reading it needs no class loader lookup.
This was referenced Sep 29, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
JindoFileIOonly appends the DLF access tracking info (dlf.access-tracking.extended-info) tofs.oss.user.agent.extended, sodls://requests lose it. Paimon itself is identified only through the SDK's call-stack detection, as a barePaimonwithout a version, and the catalog-wideuser-agent.*options that the other Paimon clients read are ignored.JindoFileIOnow fillsfs.oss.user.agent.*andfs.dls.user.agent.*with Paimon's unified User-Agent format,<module>(<transport>[;<feature>...])[ <extended>], the onepaimon-oss(#10306), the REST client (#10308), pypaimon and paimon-rust adopt as well:Paimon/<version>leads the features. The version is written in at build time by thetemplating-maven-plugin, so no class loader lookup is involved.user-agent.module,user-agent.featuresanduser-agent.extendedapply unless thefs.<scheme>.user.agent.*key for that part is set.dlf.access-tracking.extended-infois appended after the extended part for both schemes, so it never replaces a user-set value.Examples:
JindoSDK/6.9.1-nextarch(coro_http;Paimon/2.2-SNAPSHOT)user-agent.features=Flink,user-agent.extended=vvrJindoSDK/6.9.1-nextarch(coro_http;Paimon/2.2-SNAPSHOT;Flink) vvrJindoSDK/6.9.1-nextarch(coro_http;Paimon/2.2-SNAPSHOT;Flink) vvr tenantId/<uid> principalType/<type> userName/<name>fs.oss.user.agent.features=morax/2.6.0in additionJindoSDK/6.9.1-nextarch(coro_http;Paimon/2.2-SNAPSHOT;morax/2.6.0) vvr ...Related: #10306 (Java OSS), #10308 (Java REST). The three PRs only share the
templating-maven-pluginentry in the rootpom.xml.Tests
TestJindoUserAgent: 5 new cases; the existingTestJindoDlfAccessTrackingstill passes, 27 tests inpaimon-jindopassed. Also checked on a live DLF catalog with access tracking enabled: the OSS access log showsPaimon/<version>, the configured features and extended part, and the tracking info.