SOLR-13027 Use TestInjection so that we always have a Tragic Event
When we encounter a tragic error in the index writer, we can trigger a
leader election instead of queing up a delete and re-add of the node in
question. This should result in a more graceful transition, and the
previous leader will eventually be put into recovery by a new leader.
closes#2120
Prior to this change, it was not feasible to write a custom aggregate function in plugin code
because the FacetContext class did not expose its fields for access outside its package. Also
some of the useful abstract classes for SlotAcc were package-private too
Adds two metrics to the SolrCloud Overseer: solr_metrics_overseer_stateUpdateQueueSize and solr_metrics_overseer_collectionWorkQueueSize with corresponding entries in the the Prometheus exporter's default/stock configuration.
Co-authored-by: Saatchi Bhalla <s.bhalla@salesforce.com>
This addresses review feedback from David Smiley on Jira. It moves the request registration to the ContentStreamHandlerBase class instead of doing a hack-ish instanceof check inside HttpSolrCall.
* Reduced dependencies from Solr server down to just SolrJ. Don't add WEB-INF/lib.
* Was missing some dependencies in lib/; now has all except SolrJ & logging.
* Can run via gradle, "gradlew run"
* Has own log4j2.xml now
Has own CHANGES.md now.
The Dockerfile should not initialize /var/solr's contents because this is confusing and redundant with init_var_solr.sh.
No need for init_var_solr.sh to echo what it does; VERBOSE can be used to accomplish that.
Separate CHANGES.md for Docker and contrib modules.
This adds a switch to `Lucene80DocValuesFormat` which allows to
configure whether to prioritize retrieval speed over compression ratio
or the other way around. When prioritizing retrieval speed, binary doc
values are written using the exact same format as before more aggressive
compression got introduced.
Docs fetched from the update log via RTG look different than docs
fetched from commits in the index: the types of
field-values may be different between the two, etc.
This is a problem for atomic add/remove of field values, where matching
existing values has historically been done by object equals() calls (via
Collection operations). This relies on equality checks which don't have
flexible enough semantics to match values across these different types.
(For example, `new Long(1).equals(new Integer(1))` returns `false`).
This was causing some add-distinct and remove operations on
uncommitted values to silently fail to remove field values.
This commit patches over this by converting between types in the more
common cases before using the fallback behavior.
