lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "alessandro.benedetti" <>
Subject RE: DistributedUpdateProcessorFactory was explicitly disabled from this updateRequestProcessorChain
Date Fri, 21 Apr 2017 08:07:48 GMT
Let's make a quick differentiation between PRE and POST processors in a Solr
Cloud atchitecture :

 "In a single node, stand-alone Solr, each update is run through all the
update processors in a chain exactly once. But the behavior of update
request processors in SolrCloud deserves special consideration. " cit. wiki

All the processors defined BEFORE the distributedUpdateProcessor happen ONLY
on the first node that receive the update ( regardless if it is a leader or
a replica ).

The distributedUpdateProcessor will forward the update request to the the
correct leader ( or multiple leaders if the request involves more shards),
the leader will then forward to the replicas.
The leaders and replicas at this point will execute all the update request
processors defined AFTER the distributedUpdateProcessor.

" Pre-processors and Atomic Updates
Because DistributedUpdateProcessor is responsible for processing Atomic
Updates into full documents on the leader node, this means that
pre-processors which are executed only on the forwarding nodes can only
operate on the partial document. If you have a processor which must process
a full document then the only choice is to specify it as a post-processor."

In your example, your chain is definitely messed up, the order is important
and you want your heavy processing to happen only on the first node.

For better info and clarification: ( you can
find here a working alternative to your chain)

Alessandro Benedetti
Search Consultant, R&D Software Engineer, Director
Sease Ltd. -
View this message in context:
Sent from the Solr - User mailing list archive at

View raw message