[
https://issues.apache.org/jira/browse/SUREFIRE-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17238936#comment-17238936
]
Tibor Digana commented on SUREFIRE-1863:
----------------------------------------
Well, clearing the flag was always in Surefire. The other occurrences of
{{Thread.interrupted()}} do not interact with the user's code and test events,
so therefore we should concentrate only at
{{LegacyMasterProcessChannelEncoder#write( ByteBuffer frame, boolean sync )}}.
We have restore the flag in the finally block.
Let's go back to your previous question.
|| Clearing the interrupt doesn't ensure that the thread won't be interrupted
after it has been cleared.
I know what you mean regarding the code clarity, but we should not influence
user's code by the errors of our code, so they are two types of code. Here our
code is able to cope with the interrupted Thread happened in our Surefire code
and it is different exception from the typical Java IO. We are using Java NIO
API, and there the {{WritableByteChannel#write()}} method throws
{{ClosedByInterruptException}} (has the semantics of the InterruptedException)
which extends {{AsynchronousCloseException}} extends {{ClosedChannelException}}
extends {{IOException}}. In the following snippet code we catch all
{{IOException}}-s and they go to the logger (we also handle the exception after
thread interruption - just another type of exception). We do not recover the
flag if it happens in our code, because simply the user should not care - fault
tolerant but the information goes to the log.
{code:java}
private void write( ByteBuffer frame, boolean sync )
{
final boolean wasInterrupted = Thread.interrupted();
try
{
streamEncoder.write( frame, sync );
}
catch ( ClosedChannelException e )
{
if ( !onExit )
{
String event = new String( frame.array(), frame.arrayOffset() +
frame.position(), frame.remaining(),
streamEncoder.getCharset() );
DumpErrorSingleton.getSingleton()
.dumpException( e, "Channel closed while writing the event
'" + event + "'." );
}
}
catch ( IOException e )
{
if ( trouble.compareAndSet( false, true ) )
{
DumpErrorSingleton.getSingleton()
.dumpException( e );
}
}
finally
{
if ( wasInterrupted )
{
Thread.currentThread().interrupt();
}
}
}
{code}
> 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)
