Apache9 commented on PR #7580: URL: https://github.com/apache/hbase/pull/7580#issuecomment-3709481531
> > I mean we should just remove the getInstance method > > I explained why I didn't take the approach above. > > > However, it is possible that existing custom `AuthenticationProviderSelectors` might rely on this single-instantiation behavior and perform costly operations in their `configure` method. > > If I'm not mistaken, the motivation behind [HBASE-23347](https://issues.apache.org/jira/browse/HBASE-23347) was to allow users to implement their own `AuthenticationProviderSelector`. My concern was that some implementations out there may rely on the documented "exactly once per implementation" property, assume that `configure` is called only once, and do some heavy stuff in there. > > https://github.com/apache/hbase/blob/130453d573d6c8ac2e79345061aa4567546ac7e2/hbase-client/src/main/java/org/apache/hadoop/hbase/security/provider/AuthenticationProviderSelector.java#L34-L39 > > That said, I can't decide if we should be concerned about the possibility. If user just initialize one RpcClient in their program, then removing the singleton pattern does not break anything, we still only initialize the provider once. And the old behavior is incorrect if users choose to connect to different hbase clusters in a single process, so it does not make sense to keep the old behavior and try to fix only one of the possible problems with a very hacky way and leave lots of potential problems out there... I prefer we just remove the singleton pattern, add release note and update the ref guide about this behavior change, and make new releases. About the test, please extend TestBasicReadWriteWithDifferentConnectionRegistries instead of TestRpcConnectionRegistry, as TestRpcConnectionRegistry does not have any table read write requests, it just tests connection registry APIs... -- 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]
