Add debug log for flush for IndicesRequestCacheIT#39475
Add debug log for flush for IndicesRequestCacheIT#39475mayya-sharipova merged 2 commits intoelastic:masterfrom
Conversation
Add debug log when index is flushed to investigate a failure in IndicesRequestCacheIT "DEBUG" level is used as "TRACES" produces too much output irrelevant for this issue Relates to elastic#32827
|
Pinging @elastic/es-search |
colings86
left a comment
There was a problem hiding this comment.
I left a couple of suggestions in case we can get extra information but I'll leave them up to you as I'm not sure about the risk that the extra logging might cause the test failure to not reproduce due to changing the timing so there is probably an argument for being careful how much we do at one time.
| logger.trace("finished commit for flush"); | ||
|
|
||
| // a temporary debugging to investigate test failure - issue#32827. Remove when the issue is resolved | ||
| logger.debug("new commit on flush"); |
There was a problem hiding this comment.
It might help to know which of the conditions (indexWriter.hasUncommittedChanges(), force or shouldPeriodicallyFlush()) triggered this flush to help us work out what is causing this?
| import static org.hamcrest.Matchers.greaterThan; | ||
|
|
||
| @TestLogging(value = "org.elasticsearch.indices.IndicesRequestCache:TRACE") | ||
| @TestLogging(value = "org.elasticsearch.indices.IndicesRequestCache:TRACE,org.elasticsearch.index.engine.Engine:DEBUG") |
There was a problem hiding this comment.
I wonder if we should actually enable trace logging on the Engine for this test? My thought here is with trace logging we might also be able to see if the unexpected flush is waiting for an ongoing flush or if its acquired immediately?
|
@cbuescher, @colings86 thanks for the review |
|
@elasticmachine run elasticsearch-ci/1 |
Add debug log when index is flushed to investigate a failure in IndicesRequestCacheIT "DEBUG" level is used as "TRACE" produces too much output irrelevant for this issue Relates to #32827
In the context of of a recurring test failure tracked by elastic#32827, we added trace logging and an extra cache key renderer argument to IndicesRequestCache#getOrCompute (see elastic#39475 and elastic#34180). We addressed the issue with elastic#54071, but the extra argument was left behind, with a NORELEASE comment saying it should be removed. With this commit, we remove the extra cache key rendered argument and the corresponding log lines which are not so useful without it. Closes elastic#55837
In the context of of a recurring test failure tracked by #32827, we added trace logging and an extra cache key renderer argument to IndicesRequestCache#getOrCompute (see #39475 and #34180). We addressed the issue with #54071, but the extra argument was left behind, with a NORELEASE comment saying it should be removed. With this commit, we remove the extra cache key rendered argument and the corresponding log lines which are not so useful without it. Closes #55837
…62534) In the context of of a recurring test failure tracked by elastic#32827, we added trace logging and an extra cache key renderer argument to IndicesRequestCache#getOrCompute (see elastic#39475 and elastic#34180). We addressed the issue with elastic#54071, but the extra argument was left behind, with a NORELEASE comment saying it should be removed. With this commit, we remove the extra cache key rendered argument and the corresponding log lines which are not so useful without it. Closes elastic#55837
In the context of of a recurring test failure tracked by #32827, we added trace logging and an extra cache key renderer argument to IndicesRequestCache#getOrCompute (see #39475 and #34180). We addressed the issue with #54071, but the extra argument was left behind, with a NORELEASE comment saying it should be removed. With this commit, we remove the extra cache key rendered argument and the corresponding log lines which are not so useful without it. Closes #55837
Add debug log when index is flushed to investigate a failure
in IndicesRequestCacheIT
"DEBUG" level is used as "TRACES" produces too much output irrelevant for this
issue
Relates to #32827