adnanhemani commented on PR #1765: URL: https://github.com/apache/polaris/pull/1765#issuecomment-2932446974
@adutra thanks for taking a look :) > Hmm I looked at your code snippets but I don't see the connection between the TokenBroker bean production and the lazy loading of JdbcBasePersistenceImpl The connection is that the TokenBroker bean is RequestScoped and it does create a BasePersistence Supplier object as part of the bean initialization using the `realmContext` in the RequestScoped bean initialization. That BasePersistence Supplier is then stored in the `sessionSupplierMap` and attempted to be used during the lazy loading - which then tries to load the bean's (now-expired) `realmContext`. Not sure if this is more clear? Let me know what part that's not clear if not! > But assuming that this is happening inside a task executor thread, and the problem is RealmContext, why don't you resolve the realmId eagerly? Yes, this was my original idea - but was hard for me to construct a test case for this type of fix. Maybe this is something you've had more experience with - but using a request-scoped `realmContext` bean during a test was something I just wasn't able to do at all. Additionally, I'm just not sure that we're getting any use for continuously re-creating `JdbcBasePersistenceImpl` objects - is there really any good reason for us to lazy load this? If not, why not cache the object as-is? As a result, I'm promoting the CachedSupplier as our preferred way to solve this issue instead. But I'm not heavily tied to this approach if we have a better way to test the way that you suggested. -- 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...@polaris.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
