Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed

[Ralph Goers]

I am not at all familiar with how the stack is actually managed. I was hoping it was just an array and that the index into it was being kept track of. Since we know that we will only be adding more stack elements I would think that deferring use of that index wouldn’t be a problem. But since I have no idea how it is managed all I can really do is guess and hope.

As far as the appender calling a logger, it happens all the time. Log4j 1 had serious problems with it and could get itself in a deadlock. In Log4j 2 we handle that by wrapping each appender with an AppenderControl. The AppenderControl has a thread local guard. If the guard is set then the appenderControl just ignores the event.  But if logging for the stuff going on inside of an appender is routed to a different appender there is no problem. So recursion is not a problem. Without this most of the interesting things users do with Log4j wouldn’t be possible or at least would be hard to debug.  I have to believe that jul will have the same problem with custom handlers written by users.

Ralph

> On May 11, 2016, at 10:20 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi,
> 
> On 11/05/16 18:57, Ralph Goers wrote:
>> But my point is that if obtaining the StackFrame and Class
>> could be done so quickly that it wouldn’t add any noticeable
>> overhead we could do that in every Logger.info, debug, etc. call.
>> If we could just get the stack frame index so that we could obtain
>> the StackFrame and Class later by using the index that would be even
>> better since we would only be creating the StackFrame, etc if it is really required.
> 
> Working with stack frame indexes is at best fragile, unless
> you make a snapshot of the stack first and only used the
> index in relation to that snapshot. So I wouldn't recommend
> going that way. Furthermore to obtain such an index you
> would need to count the frames - which would mean walking the
> whole stack.
> 
> I'm still not sure I understand why an appender would
> call Logger.log. That sounds like a recipe for stack
> overflow or endless ping pong loops.
> I understand that could theoretically happen but then the
> appender would need to protect itself against 'logging
> while logging'. Or am I misunderstanding?
> 
> best regards,
> 
> -- daniel
>