[
https://issues.apache.org/jira/browse/SOLR-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279084#comment-17279084
]
Chris M. Hostetter commented on SOLR-15011:
-------------------------------------------
things that concern me about this test...
* there is no validation that the initial "/admin/logging" request -- where the
"nodes=all" param is being sent -- is successful. so it's possible the later
assertion failure is actaull due to a reported failure in the set request that
was ignored
* inside the node loop, what does the "nodes" param do?
** i thought this change was only to distribute the "set" commands?
** if the "read" aspects are support to also be distributale then this test is
a poor way to check it since each node is only asked about itself
** what is expected to happen if no "nodes" param is specified? ... what if a
"nodes" param is specified and is garbage input?
* what exactly is the assertEquals trying to assert? ... that the 5th logger
listed will be a WARN? ... why/how is there any reason to assume the
"com.codahale.metrics.jmx.JmxReporter:WARN" applies ot hte 5th logger listed?
In general i'd like to request that whatever the expected behavior of the
"nodes" param is (on "write" and/or "read" operations) be spelled out in the
"Loglevel API" section of the "configuring-logging.adoc" ref-guide page (this
issue added a few words about the new check box in the UI, but nothing for
people using the API programatically)
> /admin/logging handler should be able to configure logs on all nodes
> --------------------------------------------------------------------
>
> Key: SOLR-15011
> URL: https://issues.apache.org/jira/browse/SOLR-15011
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: logging
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 3.5h
> Remaining Estimate: 0h
>
> The LoggingHandler registered at /admin/logging can configure log levels for
> the current node. This is nice but in SolrCloud, what's needed is an ability
> to change the level for _all_ nodes in the cluster. I propose that this be a
> parameter name "distrib" defaulting to SolrCloud mode's status. An admin UI
> could have a checkbox for it. I don't propose that the read operations be
> changed -- they can continue to just look at the node you are hitting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
