lokiore commented on PR #2027: URL: https://github.com/apache/phoenix/pull/2027#issuecomment-2483888039
> Yes, that sounds like the correct solution. @stoty from the discussion, there are couple of options for this ticket. - Go with current updated patch (Your modified patch would still have the perf regression when kerberos is changed, though.) As far as my understanding, we want ConnectionInfo as immutable object and updating configuration at ConnectionInfo level will make it different from config in Builder and we will have to keep them in sync which can be done, but maybe we can just create a new config here as it was same before [PHOENIX-6523](https://issues.apache.org/jira/browse/PHOENIX-6523), and for perf regression here, assuming we only login for every some hours one time and kerberos change won't be for every connection creation? As it was there before as well and wasn't really a problem and can be improved with next ticket for below > 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. And sure I would like to take this up and will create another ticket for same.. -- 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
