Dear Wiki user, You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.
The following page has been changed by HossMan: http://wiki.apache.org/solr/SolrConfigXml The comment on the change is: clarify about differnet types of event listeners ------------------------------------------------------------------------------ == Update Handler Section == + The Update Handler section mostly relates to low level information about how updates are handled internally (do not confuse with higher level configuration of "Request Handlers" for dealing with updates sent by clients) - You can list multiple events in the updateHandler but do not change - `updateHandler class="solr.DirectUpdateHandler2"`. {{{ <updateHandler class="solr.DirectUpdateHandler2"> + + <!-- Limit the number of deletions Solr will buffer during doc updating. + + Setting this lower can help bound memory use during indexing. + --> + <maxPendingDeletes>100000</maxPendingDeletes> <!-- autocommit pending docs if certain criteria are met. Future versions may expand the available criteria --> @@ -52, +57 @@ <maxDocs>10000</maxDocs> <!-- maximum uncommited docs before autocommit triggered --> <maxTime>86000</maxTime> <!-- maximum time (in MS) after adding a doc before an autocommit is triggered --> </autoCommit> + + ... + }}} + + + === "Update" Related Event Listeners === + + Within the Update Handler Section, you can define listeners for particular "update" related events: "postCommit" and "postOptimize". Listeners can be used to fire-off any special code; they are typically used to exec snapshooter. + + {{{ + ... <!-- The RunExecutableListener executes an external command. exe - the name of the executable to run @@ -184, +200 @@ <enableLazyFieldLoading>false</enableLazyFieldLoading> }}} - == Searcher Section == + === "Query" Related Event Listeners === - Use this section to define a listener for a particular events — '''listener events''' that you can use to fire-off special code — such as code that invokes some common queries to warm-up caches. You can have a great number of individual queries in both Searcher sections — for example, objects that you know will ALWAYS be requested — and therefore should be auto-warmed in every new searcher. + Withing the Query section, you can define listeners for particular "query" related events — listeners can be used to fire-off special code — such as invoking some common queries to warm-up caches. - === New Searcher === + ==== newSearcher ==== - Use this section to define a listener for a particular event — the New Searcher event. A new Searcher is opened when a (current) Searcher already exists. In the example below, the listener is of the class, !QuerySenderListener, which takes lists of queries and sends them to the new searcher being opened, thereby warming it. + A New Searcher is opened when a (current) Searcher already exists. In the example below, the listener is of the class, !QuerySenderListener, which takes lists of queries and sends them to the new searcher being opened, thereby warming it. {{{ <!-- a newSearcher event is fired whenever a new searcher is being @@ -215, +231 @@ --> }}} - === First Searcher === + ==== firstSearcher ==== - Use this section to define a listener for a the First Searcher event. A First Searcher is opened when there is _no_ existing (current) Searcher. In the example below, the listener is of the class, !QuerySenderListener, which takes lists of queries and sends them to the new searcher being opened, thereby warming it. (If there is no Searcher, you cannot use auto-warming because auto-warming requires an existing Searcher.) + A First Searcher is opened when there is _no_ existing (current) Searcher. In the example below, the listener is of the class, !QuerySenderListener, which takes lists of queries and sends them to the new searcher being opened, thereby warming it. (If there is no Searcher, you cannot use auto-warming because auto-warming requires an existing Searcher.) {{{ <!-- a firstSearcher event is fired whenever a new searcher is being
