During the request, the parser plugin is retrieved from a PluginBag on the SolrCore object, so it should be reloaded at the same time as the update component (which comes from another PluginBag on SolrCore). If the components are deployed with consistent configuration in solrconfig.xml, any given SolrCore instance should have a consistent set of both. If you want to avoid repeating the information, one possibility is to use a system property https://lucene.apache.org/solr/guide/8_4/configuring-solrconfig-xml.html#jvm-system-properties though the suitability of that may depend on the size of your cluster and your deployment infrastructure.
On Thu, Jun 25, 2020 at 2:47 PM Mikhail Khludnev <m...@apache.org> wrote: > Hello, Vincenzo. > Please find above about a dedicated component doing nothing, but just > holding a config. > Also you may extract config into a file and load it by > SolrResourceLoaderAware. > > On Thu, Jun 25, 2020 at 2:06 PM Vincenzo D'Amore <v.dam...@gmail.com> > wrote: > > > Hi Mikhail, yup, I was trying to avoid putting logic in Solr. > > Just to be a little bit more specific, consider that if the update > factory > > writes a field that has a size of 50. > > The QParser should be aware of the current size when writing a query. > > > > Is it possible to have in solrconfig.xml file a shared configuration? > > > > I mean a snippet of configuration shared between update processor factory > > and QParser. > > > > > > On Wed, Jun 24, 2020 at 10:33 PM Mikhail Khludnev <m...@apache.org> > wrote: > > > > > 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 > > > > > > > > > -- > > Vincenzo D'Amore > > > > > -- > Sincerely yours > Mikhail Khludnev > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
