-
Notifications
You must be signed in to change notification settings - Fork 25.2k
More verbose logging in IndicesSegmentsRestCancellationIT
#113844
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More verbose logging in IndicesSegmentsRestCancellationIT
#113844
Conversation
Pinging @elastic/es-distributed (Team:Distributed) |
issueUrl = "https://github.com/elastic/elasticsearch/issues/88201", | ||
value = "org.elasticsearch.http.BlockedSearcherRestCancellationTestCase:DEBUG" | ||
+ ",org.elasticsearch.transport.TransportService:TRACE" | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this test for comparison? The test failure ticket doesn't appear to mention testIndicesSegmentsRestCancellation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's unclear whether they're really different or not, and given that it's only failing once every few months it seems wise to gather more data here.
try { | ||
searcherBlock.acquire(); | ||
} catch (InterruptedException e) { | ||
throw new AssertionError(e); | ||
} | ||
searcherBlock.release(); | ||
|
||
if (testCaseLogger.isDebugEnabled()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check is just to ascertain whether to do work involved in preparing the DEBUG log message, right? Do we care about that performance in testing infrastructure? Or is this simply following good coding practice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test performance is less important than production performance but not totally unimportant. Probably doesn't matter here too much but a bare logger.debug()
with expensive params should just look wrong regardless of context.
@@ -57,6 +61,8 @@ | |||
*/ | |||
public abstract class BlockedSearcherRestCancellationTestCase extends HttpSmokeTestCase { | |||
|
|||
private static final Logger testCaseLogger = LogManager.getLogger(BlockedSearcherRestCancellationTestCase.class); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[opt] ESTestCase is also a test case. Could say blockedTestCaseLogger, to clarify it's this test case specifically. Or a comment saying you're deviating from the norm because there's already a logger
-- I wondered why and went to look.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really because logger
means Engine#logger
in the places we add logging here, and that's pretty noisy.
Thread.currentThread().getName(), | ||
searcherBlock.availablePermits() | ||
), | ||
new ElasticsearchException("stack trace") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIUC, this throws an exception every time debug() is called? Why would we want that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it just constructs the exception so we have a stack trace to log.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Is there anything specific you expect to see from new logging?
I'm wondering if we are calling |
💚 Backport successful
|
💚 All backports created successfully
Questions ?Please refer to the Backport tool documentation |
…113844) Relates elastic#88201 (cherry picked from commit cd42719)
Relates #88201