JTaky commented on PR #10156:
URL: https://github.com/apache/paimon/pull/10156#issuecomment-6211247844
> Requirement fit: SUPPORTED. Implementation: FINDINGS. The previous
physical-warehouse namespace and Spark Curator access issues are repaired, but
the filesystem use case in the PR purpose is still not connected to this
implementation.
>
> [P1] Wire ZooKeeper selection into the filesystem catalog
>
> The new ZooKeeperCatalogLockFactory is discoverable, but FileSystemCatalog
still inherits AbstractCatalog.lockFactory() returning Optional.empty()
(AbstractCatalog.java:143–145). FileSystemCatalogFactory/CatalogFactory do not
install another locking policy. CatalogEnvironment.snapshotCommit consequently
obtains EmptyLock through either catalog reconstruction or the null-factory
path. Setting metastore=filesystem, lock.enabled=true and lock.type=zookeeper
therefore silently leaves actual table commits unlocked. Only the existing
Hive/JDBC catalog overrides currently discover lock.type.
> described inline; the separate Python 3.6 REST filter failure is outside
this Java diff. No source fixes were pushed.
Addressed. FileSystemCatalog now resolves the configured catalog lock
factory using the shared lock.enabled and lock.type options. The original
CatalogContext is retained by FileSystemCatalogLoader, so reconstructed
catalogs use the same locking policy. I added an end-to-end test that creates a
filesystem catalog and table through CatalogFactory and verifies that the real
table commit blocks behind the corresponding ZooKeeper lock.
--
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]
