Logging: ZkStateReader.getLeaderRetry to TRACE - #4696
Conversation
from DEBUG. But if there's a cache miss, other ZkStateReader watcher registrations will now log at DEBUG.
| } | ||
|
|
||
| public void registerLiveNodesListener(LiveNodesListener listener) { | ||
| log.debug("registerLiveNodesListener"); |
There was a problem hiding this comment.
note: called indirectly via waitForState if there was not a cache hit
| */ | ||
| public void registerDocCollectionWatcher( | ||
| String collection, DocCollectionWatcher docCollectionWatcher) { | ||
| log.debug("registerDocCollectionWatcher collection={}", collection); |
There was a problem hiding this comment.
note: called indirectly via waitForState if there was not a cache hit
|
The new logs look fine. Do the other ones really happen enough that they need to be trace logs? Debug is already quite verbose and I can't imagine these logs are really taking that much of the overall output |
|
In our production system, we saw log messages all day at a concerning volume, even though the cluster geometry was static. As "little" as a thousand a minute across our cluster but usually much more. I suspect maybe it could be indirectly related to TLOG replica polling across hour hundreds of replicas, but I'm unsure. BTW I hate that the follower polls; so sad. I filed https://issues.apache.org/jira/browse/SOLR-18331 to capture the wish. |
2 participants
from DEBUG.
But if there's a cache miss, other ZkStateReader watcher registrations newly added will now log at DEBUG.
Inspired to do this change from logging at DEBUG level of ZkStateReader on a cluster with all TLOG replica types. It seems getLeaderRetry is invoked often, albeit I expect the value to be in the cache.