[
https://issues.apache.org/jira/browse/SOLR-18549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Shanin updated SOLR-18549:
-------------------------------
Description:
🤖 _AI text below_ 🤖 _(posted on behalf of Nick Shanin)_
Related: SOLR-18317 (the Admin UI half of the same report), SOLR-15823 (open;
V2 logging broadcast).
The {{nodes}} and {{node}} parameters on a standalone node (not running in
SolrCloud) fail with a
NullPointerException, or with a 500 error that wraps one, in four endpoints:
* {{/admin/info/logging}} (v1), for reads and for {{set}}
* {{/admin/info/system}} (v1)
* {{/api/node/system}} (v2)
* {{/admin/metrics}} (v1), with {{node}}
The {{nodes}} and {{node}} parameters on a standalone node (not running in
SolrCloud) fail with a NullPointerException, or with a 500 error that
wraps one, in four endpoints:
* {{/admin/info/logging}} (v1), for reads and for {{set}}
* {{/admin/info/system}} (v1)
* {{/api/node/system}} (v2)
* {{/admin/metrics}} (v1), with {{node}}
For example, {{GET /solr/admin/info/logging?nodes=all}} fails. A {{set}}
request with {{nodes=all}} applies the level change on the node and then fails
the same way. The shared proxy code (RemoteRequestProxy.validateNodeNames and
GenericV1RequestProxy.shouldProxy) reads the ZooKeeper controller without
checking that one exists. The Admin UI no longer sends {{nodes=all}} in
standalone mode, but other clients, older UIs and direct calls still get the
error.
Expected behavior:
* {{{}/admin/info/logging{}}}, {{/admin/info/system}} and
{{{}/api/node/system{}}}: {{nodes=all}} is answered by the node itself. Other
{{nodes}} values return 400 with a message that the parameter requires
SolrCloud mode.
* {{{}/admin/metrics{}}}: {{node=all}} and explicit node names return 400
with the same kind of message.
Outside this ticket: the V2 logging endpoint
({{{}/api/node/logging/levels{}}}). SOLR-15823 gives it a 400 for {{nodes}} in
standalone mode. Open question: should the V2 logging endpoint answer
{{nodes=all}} locally too, for consistency with v1? This ticket does not decide
it.
was:
🤖 _AI text below_ 🤖 _(posted on behalf of Nick Shanin)_
Related: SOLR-18317 (the Admin UI half of the same report), SOLR-15823 (open;
V2 logging broadcast).
The \{{nodes}} and \{{node}} parameters on a standalone node (not running in
SolrCloud) fail with a
NullPointerException, or with a 500 error that wraps one, in four endpoints:
* \{{/admin/info/logging}} (v1), for reads and for \{{set}}
* \{{/admin/info/system}} (v1)
* \{{/api/node/system}} (v2)
* \{{/admin/metrics}} (v1), with \{{node}}
The \{{nodes}} and \{{node}} parameters on a standalone node (not running in
SolrCloud) fail with a NullPointerException, or with a 500 error that
wraps one, in four endpoints:
* \{{/admin/info/logging}} (v1), for reads and for \{{set}}
* \{{/admin/info/system}} (v1)
* \{{/api/node/system}} (v2)
* \{{/admin/metrics}} (v1), with \{{node}}
For example, \{{GET /solr/admin/info/logging?nodes=all}} fails. A \{{set}}
request with \{{nodes=all}} applies the level change on the node and then
fails the same way. The shared proxy code
(RemoteRequestProxy.validateNodeNames and GenericV1RequestProxy.shouldProxy)
reads the ZooKeeper
controller without checking that one exists. The Admin UI no longer sends
\{{nodes=all}} in standalone mode, but other clients, older UIs and
direct calls still get the error.
Expected behavior:
* \{{/admin/info/logging}}, \{{/admin/info/system}} and
\{{/api/node/system}}: \{{nodes=all}} is answered by the node itself. Other
\{{nodes}} values
return 400 with a message that the parameter requires SolrCloud mode.
* \{{/admin/metrics}}: \{{node=all}} and explicit node names return 400 with
the same kind of message.
Outside this ticket: the V2 logging endpoint (\{{/api/node/logging/levels}}).
SOLR-15823 gives it a 400 for \{{nodes}} in standalone mode. Open
question: should the V2 logging endpoint answer \{{nodes=all}} locally too,
for consistency with v1? This ticket does not decide it.
> Standalone node throws NPE for nodes or node parameters in proxy-capable
> admin endpoints
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-18549
> URL: https://issues.apache.org/jira/browse/SOLR-18549
> Project: Solr
> Issue Type: Bug
> Reporter: Nick Shanin
> Priority: Major
>
> 🤖 _AI text below_ 🤖 _(posted on behalf of Nick Shanin)_
> Related: SOLR-18317 (the Admin UI half of the same report), SOLR-15823 (open;
> V2 logging broadcast).
> The {{nodes}} and {{node}} parameters on a standalone node (not running in
> SolrCloud) fail with a
> NullPointerException, or with a 500 error that wraps one, in four endpoints:
> * {{/admin/info/logging}} (v1), for reads and for {{set}}
> * {{/admin/info/system}} (v1)
> * {{/api/node/system}} (v2)
> * {{/admin/metrics}} (v1), with {{node}}
> The {{nodes}} and {{node}} parameters on a standalone node (not running in
> SolrCloud) fail with a NullPointerException, or with a 500 error that
> wraps one, in four endpoints:
> * {{/admin/info/logging}} (v1), for reads and for {{set}}
> * {{/admin/info/system}} (v1)
> * {{/api/node/system}} (v2)
> * {{/admin/metrics}} (v1), with {{node}}
> For example, {{GET /solr/admin/info/logging?nodes=all}} fails. A {{set}}
> request with {{nodes=all}} applies the level change on the node and then
> fails the same way. The shared proxy code
> (RemoteRequestProxy.validateNodeNames and GenericV1RequestProxy.shouldProxy)
> reads the ZooKeeper controller without checking that one exists. The Admin UI
> no longer sends {{nodes=all}} in standalone mode, but other clients, older
> UIs and direct calls still get the error.
> Expected behavior:
> * {{{}/admin/info/logging{}}}, {{/admin/info/system}} and
> {{{}/api/node/system{}}}: {{nodes=all}} is answered by the node itself. Other
> {{nodes}} values return 400 with a message that the parameter requires
> SolrCloud mode.
> * {{{}/admin/metrics{}}}: {{node=all}} and explicit node names return 400
> with the same kind of message.
> Outside this ticket: the V2 logging endpoint
> ({{{}/api/node/logging/levels{}}}). SOLR-15823 gives it a 400 for {{nodes}}
> in standalone mode. Open question: should the V2 logging endpoint answer
> {{nodes=all}} locally too, for consistency with v1? This ticket does not
> decide it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]