Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Duplicate
-
3.0.0-M5
-
None
-
None
Description
Surefire-api clears the interrupted flag sometimes but not consistently in any code which writes to the console.
It is not expected that writing to the console would result in clearing the interrupted flag nor is it easy to trace this is the cause when it does.
The line of code causing this has a warning that it's result is ignored and probably shouldn't be.
{{
//noinspection ResultOfMethodCallIgnored
Thread.interrupted();
}}
The stack trace
{{
Thread.interrupted() called
at org.apache.maven.surefire.booter.spi.LegacyMasterProcessChannelEncoder.encodeAndPrintEvent(LegacyMasterProcessChannelEncoder.java:310)
at org.apache.maven.surefire.booter.spi.LegacyMasterProcessChannelEncoder.setOutErr(LegacyMasterProcessChannelEncoder.java:204)
at org.apache.maven.surefire.booter.spi.LegacyMasterProcessChannelEncoder.stdOut(LegacyMasterProcessChannelEncoder.java:190)
at org.apache.maven.surefire.api.booter.ForkingRunListener.writeTestOutput(ForkingRunListener.java:133)
at org.apache.maven.surefire.api.report.ConsoleOutputCapture$ForwardingPrintStream.println(ConsoleOutputCapture.java:131)
at net.openhft.chronicle.threads.DiskSpaceMonitor.pollDiskSpace(DiskSpaceMonitor.java:113)
}}
The last line of code calls System.out.println(abc);
Instead of discarding the interrupted flag, I suggest setting it again in a finally block when exiting the sensitive code or it's not cleared unexpectedly.
If this is expected behaviour, I suggest producing a warning that it was cleared so you work out why certain tests to detect the behaviour of an interrupted thread, fail when run in surefire.
Attachments
Issue Links
- duplicates
-
SUREFIRE-1815 Thread interrupted state cleared on any console output
- Closed