On 4/24/2013 1:05 AM, [email protected] 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
_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
