On 4/24/2013 1:05 AM, cyril.lapinte@free.fr wrote:

Ceki,

Thanks a lot for your time & support. I am really having a good time here !

Good to hear.

I think i got the stacktrace reading right now ! (Do I feel that I really look like a beginner ? ;-) )

So the append method in DelayingListAppender is either not entered (at least beyond the try instruction), or their is something wrong with interrupted attribute of this class.

Another possibility is fo DelayingListAppender to complete its 100 ms sleep *before* asyncAppenderBase.stop() has a chance to interrupt DelayingListAppender.

From what you just said :

...

The workerShouldStopEvenIfInterruptExceptionConsumedWithinSubappender test assumes that the main thread will finish before DelayingListAppender completes the 100ms wait. If the host machine is slow or very busy, this assumption is sometimes incorrect.

We can assume that we mostly entered the append method, right ?

I am guessing that DelayingListAppender.append(e) completes before it can be interrupted.

Since the value is set to true by the worker, could it be that the new value stay in the worker cache thread and is never communicate to the main thread ? If that is right, we would need to set the attribute volatile. But I don't see right now (way over midnight) any way to demonstrate it.

Yep, that's a very plausible hypothesis. Setting "interrupted" to volatile would address the issue of the variable being cached. If however, the first hypothesis is the actual cause, we would need to make sure that DelayingListAppender waits indefinitely on a lock until it is interrupted. I don't see a way of choosing between the two hypotheses.

Best regards, Cyril