uschindler commented on issue #13101: URL: https://github.com/apache/lucene/issues/13101#issuecomment-1945923223
Hi, I think you should also open an issue in Apache Solr, because basically the problem is more on Solr's side. As said before th I also thought yesterday evening about the same ide: Allowing to clear the cache. The problem with that is the following: I could think of another idea: - Add another method or boolean parameter to SPI lookup classes (there are many: Codec, PostingsFormat, ....) to enforce cleaning the cache before refresh. Actually the whole thing must be somehow synchronized - I haven't looked at the code for long time. - Solr calls that method with the extra "clear=true" parameter. I could live with that, but I have to state: It is just a workaround for something that is generally broken in Solr. JARs/plugins with Analysis components should be installed in the uber Solr classloader and not per core. This has already brought various problems with ICU plugin and hundreds of support issues of people that have no idea where to place the JAR file and which config files to change. It also caused hazard if different versions of same SPI components lurking in different cores. This would also cause major hazards here. I tend to think that Solr should "deprecate" the per-Core classloader and have the "lib/" syntax not in solrconfig.xml but in the solr.xml that boots the Solr framework. This is why I think there should be a separate Solr issue. The current behaviour of the existing method should not be changed, as it works like other SPI components seen in Java's core framework. All of them cache the loaded SPIs (XML components, PNG image loaders, filesystems,....). Lucene only has the option to find "new ones" not yet discovered (to add ones suddenly dropped in or for plugins running in separate classloaders like Elasticserach/Opensearch has). But those plugins should never be unloaded. Therefore removing no longer visible SPIs from the cache is against the usual conventions in Java world. P.S.: The same problems you see with reloading web applications in Tomcat. That's the reason why nobody does that anymore (it was cool at around 2005...) but never worked. Solr's classloader per core has the same problem like Tomcat. @HoustonPutman I am not familar with recent plugin architecture: Do we have "Server level plugins in Solr already". I'd really suggest to make sure that people can't loaded analysis or codec/postingsformat/... (+ soon to be coming vector similarities) for individual core but have to install those plugins top-level in Solr's main class loader. -- 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...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
