[ 
https://issues.apache.org/jira/browse/LOG4J2-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13722118#comment-13722118
 ] 

Remko Popma commented on LOG4J2-324:
------------------------------------

When you say "will impact performance", what do you mean? The only thing I can 
see is that the last 200 StatusData objects are held in memory for the duration 
of the process. Is memory usage the concern?

I'm interested to know more details about the performance test itself and the 
result. Would it be possible to attach these?

                
> Potential performance improvement for StatusLogger
> --------------------------------------------------
>
>                 Key: LOG4J2-324
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-324
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.0-beta8
>            Reporter: Remko Popma
>
> From discussion on the mailing list - please feel free to edit this 
> description.
> From: Ralph Goers
> To: Log4J Developers List <[email protected]>
> Sent: Wednesday, July 24, 2013 7:57 AM
> Subject: Re: Config additions, WAS: Confused: want low latency: do I need 
> BOTH async logger AND async appender??
> I think I just came up with another attribute for the JMX element. I'll have 
> to look at the status logger but I believe it is always creating a StatusData 
> object and putting it in a ring buffer so they can be printed later. This 
> will actually create a lot of objects and will impact performance. So we will 
> want to add a statusLevel attribute to the JMX element to specify what the 
> level is on the events that should be added to the buffer.
> It was actually kind of cool though as the person doing the performance test 
> looked at the JMX stats and even though the status was set to error in the 
> configuration they had lots of debug messages in JMX that were quite helpful 
> to verify a misconfiguration.
> Ralph

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to