CalvinKirs commented on PR #65644: URL: https://github.com/apache/doris/pull/65644#issuecomment-4978800240
One open design question worth discussing: **should querying `information_schema.plugins` trigger loading of not-yet-loaded plugins?** Today only authentication is lazy (external auth plugins load on first use via `ensurePluginFactoryLoaded`), but lazy loading could well become the norm for more plugin families down the road. If that happens, this table would only show whatever happens to have been loaded so far, and someone might reasonably ask for the query to force-load everything so the inventory is always complete. I'd argue we should **not** do that, and keep the query strictly read-only: - A hard rule in this design is that querying the table never executes plugin code. Loading is not just a directory scan — it spins up classloaders, instantiates factories, and calls `name()`/`description()`, all of which is third-party code. Query-triggered loading would put arbitrary plugin code back on the query path. - The query would inherit every failure mode of plugin loading. One bad jar (corrupt, class conflict, a static initializer that throws or hangs) could turn a millisecond metadata `SELECT` into a slow or failing one — and this is exactly the query an operator reaches for when things are already going wrong. - The semantics get unpredictable: a read-only query that mutates system state, and returns different results on the first vs. second run. If a monitoring job scrapes this table periodically, plugin load timing becomes "whenever the scraper happens to run." - Implementation-wise, the registry is a passive observer that doesn't own any manager. Triggering loads from `MetadataGenerator` would couple information_schema back into each plugin family's lifecycle. So the table's contract stays: it reflects what is **currently loaded** on the connected FE, not what jars sit in the plugin directories. If full visibility right after startup is a requirement, I think the right fix is on the other end: eagerly warm up lazy families during FE startup (e.g., call `loadAll` on the authentication plugin dirs after `AuthenticationIntegrationRuntime` is constructed). That keeps the query pure, and load failures surface in startup logs the same way they do for the other three families. That changes the auth module's existing lazy-load behavior though, so it's better done as a separate small PR if we decide we want it. Thoughts welcome. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
