voonhous commented on code in PR #13991:
URL: https://github.com/apache/hudi/pull/13991#discussion_r2378043742
##########
hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/transaction/lock/LockManager.java:
##########
@@ -115,9 +115,8 @@ public synchronized LockProvider getLockProvider() {
if (ReflectionUtils.hasConstructor(writeConfig.getLockProviderClass(),
metricsConstructorTypes)) {
lockProvider = (LockProvider)
ReflectionUtils.loadClass(writeConfig.getLockProviderClass(),
metricsConstructorTypes, lockConfiguration, storageConf, metrics);
- LOG.debug("Successfully loaded LockProvider with HoodieLockMetrics
support");
} else {
- LOG.debug("LockProvider does not support HoodieLockMetrics
constructor, falling back to standard constructor");
+ LOG.debug("LockProvider does not support HoodieLockMetrics param in
constructor, falling back to standard constructor");
// Fallback to original constructor without metrics
lockProvider = (LockProvider)
ReflectionUtils.loadClass(writeConfig.getLockProviderClass(),
new Class<?>[] {LockConfiguration.class,
StorageConfiguration.class},
Review Comment:
Do you think we need some cleanup for the `LockProvider` implementation
providers?
IIUC, we are doing this sort of streaming to ensure backwards compatibility
right? If this is the case, is it possible to add a new construct with the
`HoodieLockMetrics` parameter for all LockProvider implementations?
For those that do not require using it, it can then call the overloaded
constructor without the `HoodieLockMetrics` constructor similar to what you are
doing for `FileSystemBasedLockProvider`.
With this, we can remove the else block of the `ReflectionsUtil` that we are
modifying here.
--
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]
