Hello, Vincenzo. Presumably you can introduce a component which just holds a config data, and then this component might be lookedup from QParser and UpdateFactory. Overall, it seems like embedding logic into Solr core, which rarely works well.
On Wed, Jun 24, 2020 at 8:00 PM Vincenzo D'Amore <v.dam...@gmail.com> wrote: > Hi all, > > I've started to work on a couple of components very tight together. > An update processor that writes few fields in the solr index and a Query > Parser that, well, then reads such fields from the index. > > Such components share few configuration parameters together, I'm asking if > there is a pattern, a draft, a sample, some guidelines or best practices > that explains how to properly save configuration parameters. > > The configuration is written into the solrconfig.xml file, for example: > > <processor class="com.example.MyCustomProcessorFactory" > > <lst name="name"> > <str name="n1">x1</str> > <str name="n2">x2</str> > </lst> > </processor> > > And then query parser : > > <queryParser name="myqp" > class="com.example.query.MyCustomQueryParserPlugin" /> > > I'm struggling because the change of configuration on the updated processor > has an impact on the query parser. > For example the configuration info shared between those two components can > be overwritten during a core reload. > Basically, during an update or a core reload, there is a query parser that > is serving requests while some other component is updating the index. > So I suppose there should be a pattern, an approach, a common solution when > a piece of configuration has to be loaded at boot, or when the core is > loaded. > Or when, after an update a new searcher is created and a new query parser > is created. > > Any suggestion is really appreciated. > > Best regards, > Vincenzo > > > > -- > Vincenzo D'Amore > -- Sincerely yours Mikhail Khludnev
