Apache Solr Reference Guide Covering Apache Solr 6.0

etagSeed This value of this attribute is sent as the value of the ETag header. Changing this value can be
helpful to force clients to re-fetch content even when the indexes have not changed---for
example, when you've made some changes to the configuration.
max-age=30, public
cacheControl Element
In addition to these attributes, accepts one child element: . The content of
this element will be sent as the value of the Cache-Control header on HTTP responses. This header is used to
modify the default caching behavior of the requesting client. The possible values for the Cache-Control header
are defined by the HTTP 1.1 specification in Section 14.9.
Setting the max-age field controls how long a client may re-use a cached response before requesting it again
from the server. This time interval should be set according to how often you update your index and whether or
not it is acceptable for your application to use content that is somewhat out of date. Setting must-revalidate
will tell the client to validate with the server that its cached copy is still good before re-using it. This will ensure
that the most timely result is used, while avoiding a second fetch of the content if it isn't needed, at the cost of a
request to the server to do the check.
Update Request Processors
Every update request received by Solr is run through a chain of plugins known as Update Request Processor.
This can be useful, for example, to add a field to the document being indexed or to change the value of a
particular field or to drop an update if the incoming document doesn't fulfill certain criteria. In fact, a surprisingly
large number of features in Solr are implemented as Update Processors and therefore it is necessary to
understand how such plugins work and where are they configured.
Topics in this section:
Anatomy and life cycle
Configuration
Update processors in SolrCloud
Using custom chains
Update Request Processor Factories
Anatomy and life cycle
An Update Request Processor is created as part of a chain of one or more update processors. Solr creates a
default update request processor chain comprising of a few update request processors which enable essential
Solr features. This default chain is used to process every update request unless a user chooses to configure and
specify a different custom update request processor chain.
The easiest way to describe an Update Request Processor is to look at the Javadocs of the abstract class Updat
eRequestProcessor. Every UpdateRequestProcessor must have a corresponding factory class which extends Up
dateRequestProcessorFactory. This factory class is used by Solr to create a new instance of this plugin. Such a
design provides two benefits:
1.
2.
An update request processor need not be thread safe because it is used by one and only one request
thread and destroyed once the request is complete.
The factory class can accept configuration parameters and maintain any state that may be
Apache Solr Reference Guide 6.0
458