LoggingEvent Fix property

[François Dumont <fr...@free.fr>]

Hello

  In my company we are using an AsyncAppender for asynchronous logging 
that we have implemented ourselves and we are quite happy with it. From 
the start we had prepared a FixFields property on this appender so that  
user can decide which fields has to be fixed by the appender before  
passing it to nested appenders. The default value for this property is 
Partial.

  I recently try to use it so that most of the logging event formatting 
is done in the logging thread rather than in the thread that generate 
the log event. So I change the FixFields value to ThreadName and 
discovered that it has an impact on the job performed by nested 
appenders. For instance when I log an exception through a 
ConsoleAppender nested in a AsyncAppender I have normally the following 
result:

ERROR Exception raised
System.ApplicationException: FOO
 à AsyncAppenderTest.Program.ThrowException() dans 
C:\Dev\AsyncAppenderTest\AsyncAppenderTest\Program.cs:ligne 69
 à AsyncAppenderTest.Program.Main(String[] args) dans 
C:\Dev\AsyncAppenderTest\AsyncAppenderTest\Program.cs:ligne 40

Once I changed the FixFields to simply ThreadName I had:

ERROR Exception raised

As you can see the log of the exception has disappeared. This is so with 
or without the %exception in the PatternLayout.

  The problem is in the LoggingEvent class. It looks like you cannot 
partially fix a LoggingEvent. Once you fix some fields using the Fix 
property m_cacheUpdatable is set to false and when the LoggingEvent  
reference is pass to the ConsoleAppender which call GetExceptionString 
this method return an empty string because m_cacheUpdatable is false. 
What is m_cacheUpdatable for exactly ? It looks like the intention is to 
avoid the same field to be fixed several time but as all fields default 
value in LoggingEventData is null and is not null anymore once fixed it 
seems enough to avoid the multiple fixes situation. Couldn't be 
LoggingEvent.m_cacheUpdatable simply removed ?

Thanks

Re: LoggingEvent Fix property

[François Dumont <fr...@free.fr>]

Hello

     I didn't expected to got an answer after such a long time, thanks !

     I know how I can workaround this problem. Rather than using a 
BufferingForwardingAppender I can simply fix the exception part of the 
log event when the log event is passed to my AsyncAppender in addition 
to the thread part that has to be fixed and also, as you noticed, the 
properties.

     But my question was rather: why am I forced to fix the exception in 
the thread that do the log rather than asynchronously in the logging 
thread. The point of using an asynchronous appender is to perform most 
of the job like rendering the log event asynchronously. Because of 
m_cacheUpdatable I simply cannot perform this 2 steps fixing. Thanks to 
your answer I see what was this flag purpose but I am not sure that it 
should have been generalized for all properties of LoggingEvent.

     For info I had created a Jira ticket:

https://issues.apache.org/jira/browse/LOG4NET-239

     I hope it will be considered for the future 1.2.11 release.

Regards

On 29/06/2010 07:36, Dmitri Tchikine wrote:
> François Dumont<francois.cppdevs<at>  free.fr>  writes:
>
>    
>>    In my company we are using an AsyncAppender for asynchronous logging
>> As you can see the log of the exception has disappeared. This is so with
>> ... Couldn't be
>> LoggingEvent.m_cacheUpdatable simply removed ?
>>
>>      
> I worked on the same design: asynch logging, fixing threads...
> BTW, you should fix properties too, to get proeprties from thread context.
>
> To get exception logged, you need to pass the event through
> BufferingForwardingAppender with
>      <bufferSize value="1"/>
>      <lossy value ="false"/>
>      <fix value="Exception"/>
> It will simply restore the exception, becuase, cacheUpdatable flag is set for
> the during of the fixing.
> That is to say that buffering appenders fix whatever properties, but also make
> other prperties un-used; this can be useful in complex scenarios not attempt to
> access to proeprty that should not be there (like location, which may be very
> long to aquire, and may be misleading... etc).
>
> So, somewhere along the route from logger to layout there 1) either should be no
> buffering appenders, or) one of them should Fix the exception peroperty.
> Cheers
>
>    

Re: LoggingEvent Fix property

[Dmitri Tchikine <dm...@internode.on.net>]

François Dumont <francois.cppdevs <at> free.fr> writes:

>   In my company we are using an AsyncAppender for asynchronous logging 
> As you can see the log of the exception has disappeared. This is so with 
> ... Couldn't be 
> LoggingEvent.m_cacheUpdatable simply removed ?
> 

I worked on the same design: asynch logging, fixing threads...
BTW, you should fix properties too, to get proeprties from thread context.

To get exception logged, you need to pass the event through
BufferingForwardingAppender with 
    <bufferSize value="1"/>
    <lossy value ="false"/>
    <fix value="Exception"/>
It will simply restore the exception, becuase, cacheUpdatable flag is set for
the during of the fixing.
That is to say that buffering appenders fix whatever properties, but also make
other prperties un-used; this can be useful in complex scenarios not attempt to
access to proeprty that should not be there (like location, which may be very
long to aquire, and may be misleading... etc).

So, somewhere along the route from logger to layout there 1) either should be no
buffering appenders, or) one of them should Fix the exception peroperty.
Cheers