virajjasani commented on PR #2083: URL: https://github.com/apache/phoenix/pull/2083#issuecomment-2684166077
> hbase.zookeeper.client.quorum is the primary property, and hbase.zookeeper.quorum is the fallback if the client one is undefined, there is no other semantic difference, and I think we should honor that. Yes, this is correct, and even with this change, this will be honored. ZkConnectionInfo#asProps() will return both of them. `hbase.zookeeper.client.quorum` will contain port info whereas for the purpose of backward compatibility, we want to remove port info from `hbase.zookeeper.quorum`. From the viewpoint of establishing HBase connection, there is no problem for patterns like `host1:123,host2:234,host3:345` because all port info from the url will be available to `hbase.zookeeper.client.quorum` and HBase connection will use it. However, on the other hand, let's assume we use dual-client without this patch. In that case, given that ConnectionInfo already has cached `static volatile Configuration configuration`, if we don't provide `hbase.zookeeper.quorum`, both CQSI connections (one for primary and another for secondary), even having right URL, will provide CQSI connection config value for `hbase.zookeeper.quorum` same, because it will be derived from cached config. > I think that right solution is to leave the hbase-site.xml properties alone, and just naively copy the strings from the URL into both hbase.client.zookeeper.quorum and hbase.zookeeper.quorum (and for old-style URLs also set the port properties), AND somehow store phoenix-specific property that we can use to select the correctl CQSI object. This is what I thought earlier, but any downstream application dealing with both 5.1 and 5.2 client should expect same behavior. For instance, reading `hbase.zookeeper.quorum` value from 5.1 client CQSI config and then processing some data, and now after upgrade re-reading `hbase.zookeeper.quorum` value from 5.2 client CQSI config and using it to find out earlier computed value (e.g. thread pools to be used for HTable) can easily lead into problems. I don't mind keeping same value for both `hbase.zookeeper.quorum` and `hbase.zookeeper.client.quorum`. It's the backward compatibility use case that makes me feel comfortable returning same value by both 5.1 and 5.2 clients. Again, just to re-iterate, this has no impact w.r.t HBase connection creation because as you rightly mentioned above, HBase uses `hbase.zookeeper.client.quorum` if present and ignores `hbase.zookeeper.quorum`. -- 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]
