[jira] [Commented] (LOG4J2-2923) Refactor use of Thread.sleep in tests

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17556016#comment-17556016 ] 

ASF subversion and git services commented on LOG4J2-2923:
---------------------------------------------------------

Commit 8c57bf78bcfb7b2969efa72a16d0b4948a1e4155 in logging-log4j2's branch refs/heads/master from Matt Sicker
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=8c57bf78bc ]

Make RollingNewDirectoryTest less sleepy

Relates to LOG4J2-2923.

Signed-off-by: Matt Sicker <ma...@apache.org>


> Refactor use of Thread.sleep in tests
> -------------------------------------
>
>                 Key: LOG4J2-2923
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2923
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Tests
>            Reporter: Matt Sicker
>            Assignee: Ralph Goers
>            Priority: Major
>             Fix For: 2.14.1
>
>
> While working on LOG4J2-2653, I've come across some tests that rely on the use of {{Thread.sleep}} to test effects of some (typically concurrent) code. For example, many of the rolling file appender tests rely on this for checking the results of log file rollover/compression/deletes/etc. These tests tend to be the worst offenders in execution time by about 1-3 orders of magnitude compared to typical tests (e.g., most tests execute in a fraction of a second while these sleep-inducing tests can take several seconds _each_).
> Interestingly enough, these tests are also typically the same ones that sporadically fail in CI due to timing issues. The systems under test are also typically some of the less well specified (from a formal standpoint) that receive a decent amount of bug reports and bug fixes. The difficulty of testing concurrent or parallel code has exacerbated the issue.
> Tests relying on {{Thread.sleep}} should be refactored where possible to use more appropriate concurrency APIs. For example, instead of busy-waiting in a loop waiting for a condition to appear, this can use concurrency primitives like {{CountDownLatch}} or {{CyclicBarrier}}. This may require the introduction of some package-private test hooks in various plugins to coordinate them in a test, or it may involve the introduction of natural APIs in Log4j itself (like {{ReliabilityStrategy}}).
> For tests that rely on the current time and such, these should be updated to use the configured Log4j {{Clock}} which can use a mock version in tests rather than testing the real clock (which just wastes time). There's very little reason for unit tests to be testing the passage of real time.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)