https://issues.apache.org/bugzilla/show_bug.cgi?id=47401
Summary: log4j swallowing interrupt
Product: Log4j
Version: 1.2
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: critical
Priority: P2
Component: Appender
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected]
Created an attachment (id=23847)
--> (https://issues.apache.org/bugzilla/attachment.cgi?id=23847)
log4j properties file
The issue we face is similar to parts of bug-41214, but more specific and
reproducible in a single thread. log4j version used is 1.2.15. Also this is not
specific to one appender - I've got this problem with both FileAppender and
RollingFileAppender. The following program can consistently simulate the
problem
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class issue
{
public static void main(String a[]){
Log log=LogFactory.getLog(issue.class);
log.debug(new issue());
System.err.println("Interrupt Status:
"+Thread.currentThread().isInterrupted());
}
public String toString(){
Thread.currentThread().interrupt();
return("log msg");
}
}
On an AIX with java 1.5.0, it runs correctly as displayed below:
---
bash-3.00$ uname -srv
AIX 1 6
bash-3.00$ java -cp commons-logging-1.1.1.jar:log4j-1.2.15.jar:. issue
Interrupt Status: true
bash-3.00$ cat app.log
2009-06-22 08:00:37,593 DEBUG main issue - log msg
bash-3.00$
---
However on a Solaris, with every 1.5 and 1.6 java versions used, it fails to
write the log statement instead prints an InterruptedIOException trace besides
reading/unsetting the thread's interrupt flag:
---
bash-3.00$ uname -rvs
SunOS 5.10 Generic_137137-09
bash-3.00$ java -version
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
bash-3.00$ java -cp commons-logging-1.1.1.jar:log4j-1.2.15.jar:. issue
log4j:ERROR Failed to flush writer,
java.io.InterruptedIOException
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:260)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)
at org.apache.log4j.helpers.QuietWriter.flush(QuietWriter.java:58)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:316)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:160)
at
org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
at
org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.log(Category.java:856)
at
org.apache.commons.logging.impl.Log4JLogger.debug(Log4JLogger.java:177)
at issue.main(issue.java:9)
Interrupt Status: false
bash-3.00$ cat app.log
bash-3.00$
---
Besides the trace, note that the interrupt status printed is false. Based on
the nature of log4j, even if a thread happens to be in some file writing log4j
code while receiving an interrupt and thereby gets an InterruptedIOException,
shouldn't the log4j system itself catch it and set the interrupt flag back
(that the message was not written to the log file is a smaller issue, but even
the log write operation can be reattempted without harm). In this example, the
interrupt flag was set even before any actual write.
I've a feeling that this particular issue of interrupt is still to be handled
in the log4j layer and the problem is not visible in the IBM jvm on AIX only
because it has a different interpretation of when to throw the
InterruptedIOException(may be it doesn't throw if the interrupt flag was
already set before an IO operation).
The log4j properties file is attached.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
