[
https://issues.apache.org/jira/browse/SOLR-10628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16144680#comment-16144680
]
Jason Gerlowski commented on SOLR-10628:
----------------------------------------
Ah, figured it out, the "getLogLevel" method in the patch had a bug in it:
{code}
+ /**
+ * Return a string representing the current static ROOT logging level
+ * @return a string TRACE, DEBUG, WARN, ERROR or INFO representing current
log level. Default is INFO
+ */
+ public static String getLogLevelString() {
+ final Logger rootLogger = LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME);
+ if (rootLogger.isTraceEnabled()) return "TRACE";
+ else if (rootLogger.isDebugEnabled()) return "DEBUG";
+ else if (rootLogger.isWarnEnabled()) return "WARN";
+ else if (rootLogger.isErrorEnabled()) return "ERROR";
+ else if (rootLogger.isInfoEnabled()) return "INFO";
+ else return "INFO";
+ }
{code}
The above logic will return "WARN" when the log level is set to INFO. (This is
because {{isXEnabled}} returns true if the log-level is <= X ). To correct
this logic, the severity level clauses need to be ordered in increasing order
(the {{isInfoEnabled}} line needs to come above the {{isWarnEnabled}} line).
I've tested this on single test runs and verified that the correct log-level is
getting cached/reset. Running longer test runs now before uploading a modified
patch.
> Less verbose output from bin/solr commands
> ------------------------------------------
>
> Key: SOLR-10628
> URL: https://issues.apache.org/jira/browse/SOLR-10628
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: scripts and tools
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Fix For: master (8.0), 7.1
>
> Attachments: SOLR-10628-loglevel-fix_jan.patch,
> SOLR-10628-loglevel-fix.patch, SOLR-10628.patch, SOLR-10628.patch,
> SOLR-10628.patch, SOLR-10628.patch, SOLR-10628.patch,
> solr_script_outputs.txt, updated_command_output.txt
>
>
> Creating a collection with {{bin/solr create}} today is too verbose:
> {noformat}
> $ bin/solr create -c foo
> Connecting to ZooKeeper at localhost:9983 ...
> INFO - 2017-05-08 09:06:54.409;
> org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider; Cluster at
> localhost:9983 ready
> Uploading
> /Users/janhoy/git/lucene-solr/solr/server/solr/configsets/data_driven_schema_configs/conf
> for config foo to ZooKeeper at localhost:9983
> Creating new collection 'foo' using command:
> http://localhost:8983/solr/admin/collections?action=CREATE&name=foo&numShards=1&replicationFactor=1&maxShardsPerNode=1&collection.configName=foo
> {
> "responseHeader":{
> "status":0,
> "QTime":4178},
> "success":{"192.168.127.248:8983_solr":{
> "responseHeader":{
> "status":0,
> "QTime":2959},
> "core":"foo_shard1_replica1"}}}
> {noformat}
> A normal user don't need all this info. Propose to move all the details to
> verbose mode ({{-V)}} and let the default be the following instead:
> {noformat}
> $ bin/solr create -c foo
> Connecting to ZooKeeper at localhost:9983 ...
> Created collection 'foo' with 1 shard(s), 1 replica(s) using config-set
> 'data_driven_schema_configs'
> {noformat}
> Error messages must of course still be verbose.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
