Hi Shawn, Alex, thanks for the update. In the first instance I have disabled entirely the updateRequestProcessorChain "add-unknown-fields-to-the-schema". I can confirm that since then Solr continues to handle things correctly under the hood. I agree with you, configuration should be as explicit and transparent as possible. it seems that LogUpdateProcessorFactory and RunUpdateProcessorFactory are still there, somehow. I'm only afraid of what I'm losing by not having DistributedUpdateProcessorFactory configured explicitly, is even this component present by default? Where the default processors are configured?
On Wed, Oct 12, 2022 at 7:55 PM Shawn Heisey <apa...@elyograg.org> wrote: > On 10/12/22 05:54, Vincenzo D'Amore wrote: > > Does anyone know what's the responsibility of > > DistributedUpdateProcessorFactory? > > That update processor takes care of atomic update functionality and > farming out update requests to other Solr nodes, in particular for > SolrCloud. It probably has some other functionalities, but I haven't > looked at its code recently. > > > Today I realized that in SolrCloud when disabling the schemaless mode, we > > are going to disable also: > > > > - LogUpdateProcessorFactory, > > - DistributedUpdateProcessorFactory, > > - RunUpdateProcessorFactory > > The LogUpdate processor logs the request, usually that goes to > solr.log. The RunUpdate processor actually does the update. I believe > that if any of those 3 processors are removed from a definition, they > are still automatically performed by Solr. It is better to leave them > in the definition so that anyone looking at it knows exactly what is > being done and doesn't need to know about Solr's internal implicit > handling. If you are entirely removing all processor chains, then don't > worry about it. Solr will handle things correctly. > > > Those processors don't seem to be related to the schemaless mode, in > > particular DistributedUpdateProcessorFactory. > > You are correct, they are not related to schemaless mode, but they are > important. > > Thanks, > Shawn > > -- Vincenzo D'Amore
