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
| Component | _XTRAS_LIST token |
Listens on | JVM | Heap (SOLR_JAVA_MEM) |
|---|---|---|---|---|
| Solr 9 | SR9 |
127.0.0.1:9099 |
Java 21 on Excalibur (or where /usr/lib/jvm/java-21-openjdk-amd64 exists), else Java 17 |
-Xms64m -Xmx$((RAM_MB/6))m |
| Solr 7 | SR7 (not on Excalibur) |
127.0.0.1:9077 |
Java 11 | -Xms64m -Xmx$((RAM_MB/6))m |
| Solr 4 (legacy) | SR4 (not on Excalibur) |
127.0.0.1:8099 |
Java 11 under Jetty 9 | -Xms64m -Xmx$((RAM_MB/8))m (_USE_JETTY) |
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:
| Devuan release | JDKs installed | Solr versions installable |
|---|---|---|
| Beowulf | Java 11 only | Solr 4 + Solr 7 only — Solr 9 cannot install (no /usr/bin/java17 or java21) |
| Chimaera | Java 11 + Java 17 | Solr 4 + 7 + 9 (Solr 9 via Java 17 — Chimaera does not get Java 21) |
| Daedalus | Java 11 + 17 + 21 | Solr 4 + 7 + 9 |
| Excalibur | Java 11 + 17 + 21 | Solr 9 only (the installer skips Solr 4/7 when _OS_CODE=excalibur) |
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), 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.
Pages in this section
- Overview and tuning — the per-site INI contract
(
solr_integration_module/solr_update_config/solr_custom_config), core type selection,solr.php, GC-log diagnostics, high-write core tuning, and ratio-driven index optimisation. - Solr 9 modules — the 17
.modfiles BOA ships, the five daemon-enabled viaSOLR_MODULES, and the two distinct module-load paths. - Core lifecycle —
manage_solr_config.sh: the four-minute reconciliation pass, the 3-tier orphan archival, the per-core health check, throttle sentinels, and recovery of archived cores.
Reference
- Reference appendix —
solr_integration_module,solr_update_config,solr_custom_configsite-INI variables. - Discontinued features — Solr-4-era file-edit core management, superseded by the INI mechanism.