[
https://issues.apache.org/jira/browse/SOLR-16722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706754#comment-17706754
]
Thomas Wöckinger commented on SOLR-16722:
-----------------------------------------
When using k8s with solr-operator such an API should be integrated as lifecycle
`preStop` event, this would be the right place to initiate a ordered shutdown.
Combined with`readinessProbe`it should be possible to provide all services (for
internal or external usage) without any interruption. This would have benefits
for upgrade scenarios and/or container restarts.
Just to note, if the `readinessProbe` is not successful ingress will remove it
immediately from the list of backend servers (using endpoint events).
This could be changed by configure the service with
`{{{}publishNotReadyAddresses{}}}`, but that would be something for
solr-operator.
> API to flag a solr node NOT READY for requests
> ----------------------------------------------
>
> Key: SOLR-16722
> URL: https://issues.apache.org/jira/browse/SOLR-16722
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Jan Høydahl
> Priority: Major
>
> Spinoff from solr operator PR
> [https://github.com/apache/solr-operator/issues/529]
> When solr-operator performs a rolling restart or rolling upgrade, it will
> stop one node at a time, but SolrJ (both external and internal) will continue
> sending traffic to the node until requests start failing, since at the time
> SolrJ picks up the "live_nodes" change, it is too late.
> While the operator PR mentioned above will prevent external requests through
> the k8s service to the draining node, it will not prevent internal traffic.
> This issue thus aims to introduce some API or mechanism to flag a Solr node
> as NOT READY for traffic.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
