Hi - Of the various approaches that you could take, the one I'd work on first is:
deployment constraints imply one webapp instance.
In most environments, it's going to cost a lot less to change this, than to try to roll your own, or extensively modify solr. I know I'm sidestepping your stated requirements, but I'd take a long look at that one. BTW, We cut over from an embedded Lucene instance to Solr about 4 months ago, and are very happy that we did. Tom On 4/13/07, Henrib <[EMAIL PROTECTED]> wrote:
I'm trying to choose between embedding Lucene versus embedding Solr in one webapp. In Solr terms, functional requirements would more or less lead to multiple schema & conf (need CRUD/generation on those) and deployment constraints imply one webapp instance. The choice I'm trying to make is thus: -Embed Lucene and (attempt to) recode a lot of what Solr provides... (the straw man) -Embed Solr but refactor 'some' of its core, assuming it is correct to see one Solr core as the association of one schema & one conf. There have been a few threads about multiple indexes and/or multiple/reloading schemas. From what I gathered, one solution stems from the 'multiple webapp instances deployment' and implies 'extracting' the static instance (at least the SolrCore) & thus host multiple Solr cores in one webapp. Obviously, the operations (queries/add/delete doc) would need to carry which core they are targeting (one 'core' being set as the 'default' for compatibility purpose). What will be the other big hurdles, the ones that could even preclude the very idea ? (caches handling, updater threads, HA features...) Are there any easier routes (class-loaders, 'provisional' schema...) ? Any advice welcome. Thanks. Henri -- View this message in context: http://www.nabble.com/Embedding-Solr-vs-Lucene%2C-multiple-Solr-cores--tf3572324.html#a9981355 Sent from the Solr - User mailing list archive at Nabble.com.
