stoty commented on PR #2027: URL: https://github.com/apache/phoenix/pull/2027#issuecomment-2482151517
> or I was thinking we can just update the config with these params when we are logging in actual configuration object, but I am not sure if we need them there except when we are logging in. Yes, that sounds like the correct solution. Your modified patch would still have the perf regression when kerberos is changed, though. When I did the refactor, I copied this code here with the rest of the config checks, but we do not actually need to log into Kerberos to build ConnectionInfo, this was just a convenient place to do it along with the other normalization steps in the refactors. My intent was not to change kerberos-related functionality/calls. I don't remember the exact thread/principal flow either, unfortunately. We would need to dig into whether we correctly support working on Connections with different principals correctly before/after my patch. My gut feeling is that that would require checking the current principal in every JDBC entry point, and logging into it if needed when being called, and I don't remember us doing that. Even if didn't work correctly before, we don't need to fix that in this ticket, only solve the perf regression, but we need to understand the thread/principal flow to decide where we need to perform the kerberos login optimally. It would be great if you could dig into this @lokiore. If you do not have the time/inclination, then let me know and I will take this up. -- 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: issues-unsubscr...@phoenix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
