Created attachment 23847 [details]
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.