You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "David Smiley (Jira)" <ji...@apache.org> on 2021/02/05 04:48:00 UTC
[jira] [Comment Edited] (SOLR-15011) /admin/logging handler should
be able to configure logs on all nodes
[ https://issues.apache.org/jira/browse/SOLR-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279323#comment-17279323 ]
David Smiley edited comment on SOLR-15011 at 2/5/21, 4:47 AM:
--------------------------------------------------------------
{quote}Only the JmxReporter logger will change its log level which is 5th in the list com.codahale.metrics.jmx.JmxReporter
{quote}
Okay but that's extremely presumptuous – a very brittle test. I'm embarrassed this slipped passed my code review! A better test would find the node that refers to this particular logger and check _that one_. If you use assertJQ syntax, this should be a succinct check.
{quote}throw new AssertionFailure("Exception while proxying request to node " + node, e);{quote}
+1! I've been burned when people forget this; I'm sure most of us have. It would be awesome if static analysis tools detected that a caught exception is not used, unless it's named, say, "ignored".
I tried something else that occurred to me... I merely commented out the substance of the issue (LoggingHandler calling into AdminHandlersProxy) and... the test still passed. I'm not surprised; this is an embedded test and thus all nodes share the same logging state. Hmm. I wonder if we can't realistically test this until we have Docker based test infrastructure with fully isolated Solr nodes. I know we do have some Docker tests using Bash scripts; I suppose they could be used, but I'm looking forward to having something allowing normal looking JUnit based tests one day.
was (Author: dsmiley):
{quote}Only the JmxReporter logger will change its log level which is 5th in the list com.codahale.metrics.jmx.JmxReporter
{quote}
Okay but that's extremely presumptuous – a very brittle test. I'm embarrassed this slipped passed my code review! A better test would find the node that refers to this particular logger and check _that one_. If you use assertJQ syntax, this should be a succinct check.
{quote}throw new AssertionFailure("Exception while proxying request to node " + node, e);{quote}
+1! I've been burned when people forget this; I'm sure most of us have. It would be awesome if static analysis tools detected that a caught exception is not used, unless it's named, say, "ignored".
I tried something else that occurred to me... I merely commented out the substance of the issue (LoggingHandler calling into AdminHandlersProxy) and... the test still passed. I'm not surprised; this is an embedded test and thus all JVMs effectively share the same logging state. Hmm. I wonder if we can't realistically test this until we have Docker based test infrastructure with fully isolated Solr nodes. I know we do have some Docker tests using Bash scripts; I suppose they could be used, but I'm looking forward to having something allowing normal looking JUnit based tests one day.
> /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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org