[logback-dev] logback-dev Digest, Vol 19, Issue 76

[Ceki Gülcü]

On 4/24/2013 1:05 AM, cyril.lapinte at 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