[
https://issues.apache.org/jira/browse/SUREFIRE-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238677#comment-17238677
]
Peter Lawrey commented on SUREFIRE-1863:
----------------------------------------
It is related however "1815" suggests that the wrong encoder was chosen.
However, there is 5 places in the surefire repo where `Thread.interrupted()` is
called and the result discarded even though the code analysis tool is clearly
flagging this as a concern.
The real problem is none of the code should be discarding the interrupt unless
this is clearly intended behavior
e.g. switching ChanelEncoder shouldn't change this kind of behavior as they
should all either do this consistently or not do this.
Making it use the "right" ChannelEncoder is just hiding the issue for the next
time someone uses it.
> Tests run in surefire can clear the thread interrupted flag silently when any
> message is logged to the console.
> ---------------------------------------------------------------------------------------------------------------
>
> Key: SUREFIRE-1863
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1863
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 3.0.0-M5
> Reporter: Peter Lawrey
> Assignee: Tibor Digana
> Priority: Major
>
> 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.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
