Solr search (operator)

BOA runs a per-host, multi-core Apache Solr stack bound to localhost, driven entirely from each site's boa_site_control.ini. There is no per-platform Solr state and no SolrCloud — cores are created, updated, and deleted per-site by a single reconciliation daemon (manage_solr_config.sh) on a four-minute cron pass. Three versions coexist on one host: Solr 9 (current, the only version on Excalibur), Solr 7, and Solr 4 (legacy, under Jetty 9).

The daemon's maintenance operations — orphan-core archival, index optimisation, per-core health checks, and solrcore.properties repair — run for Solr 7 (9077) and Solr 9 (9099) only. Solr 4 / Jetty 9 (8099) gets none of this: its orphan cores are never archived, never optimised, and never health-checked. Solr 4 cores are only ever created, updated, and deleted through the per-site path.

Install is opt-in via the SR9 / SR7 / SR4 tokens in _XTRAS_LIST (/root/.barracuda.cnf); the installer auto-pulls the JDK set the host OS allows. The pinned versions are _SOLR_9_VRN=9.10.1, _SOLR_7_VRN=7.7.3, _SOLR_4_VRN=4.9.1, _JETTY_9_VRN=9.2.16.v20160414 (BARRACUDA.sh.txt).

What you need running on the host

RAM_MB is free -mt total minus the BOA reserve; the heap divisor is computed in system.sh.inc (_USE_SOLR_MEM=RAM/6, _USE_JETTY_MEM=RAM/8). BOA comments out any SOLR_HEAP line and writes SOLR_JAVA_MEM instead.

Host-OS → JDK matrix (governs which Solr versions can install)

The JDK set is installed by OS, not by which Solr version you request, and it gates what can run:

The Solr 9 install gate is [ -e /usr/bin/java17 ] || [ -e /usr/bin/java21 ]; the Solr 4/7 gate is [ -e /usr/bin/java11 ] and is skipped entirely on Excalibur (solr.sh.inc). On Beowulf the dispatcher is still called, but the java gate then declines Solr 9.

Hardware impact

Enabling Solr raises BOA's documented hardware minimum from 4 GB RAM / 2 CPUs to 8 GB / 4+ CPUs. Heap is RAM-derived (see table); each loaded core — even an empty one — holds live heap (field caches, segment readers, filter caches) and open file descriptors on its index files, so core count, not index size alone, drives JVM pressure. Orphan-core accumulation is the dominant heap-exhaustion failure mode on busy multi-tenant hosts; the reconciliation daemon archives stale cores automatically on Solr 7 and Solr 9 only — Solr 4 / Jetty 9 orphan cores are never archived and accumulate until cleared by hand.

The pages below cover the per-site INI contract and tuning, the Solr 9 module set, and the reconciliation daemon behind the core lifecycle.

Reference

• Reference appendix — solr_integration_module, solr_update_config, solr_custom_config site-INI variables.
• Discontinued features — Solr-4-era file-edit core management, superseded by the INI mechanism.