[
https://issues.apache.org/jira/browse/SOLR-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14568149#comment-14568149
]
Mark Miller commented on SOLR-7615:
-----------------------------------
bq. I specifically remember having to add OR's to
LogUpdateProcessor.log.isInfoEnabled() to get that logging while using DEBUG
logging.
I do know I have never seen anything like this when changing the top level
logging to DEBUG. It always has worked as I would expect in this case. I think
I saw whatever this behavior was when I was specifically changing the logging
level for that class because I had added some test logging under debug. Who
knows - if it works the way you say, I guess no sweat.
In any case, +1 for just creating the update processor at least also on warn if
not alway.
> Slow update requests not logged at WARN due to how LogUpdateProcessor's are
> created
> -----------------------------------------------------------------------------------
>
> Key: SOLR-7615
> URL: https://issues.apache.org/jira/browse/SOLR-7615
> Project: Solr
> Issue Type: Bug
> Reporter: Timothy Potter
> Assignee: Timothy Potter
> Priority: Minor
>
> In SOLR-6650, we introduced the ability to only have slow update and query
> requests get logged as warnings. However, when tracking down the cause of
> SOLR-7603, we discovered that the LogUpdateProcessor is only included in the
> chain if the log has INFO enabled, thus rendering the solution provided by
> SOLR-6650 useless for update requests (queries still work though).
> Thus, we need to fix how LogUpdateProcessor is created if the user has
> configured slowUpdateThresholdMillis > 0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
