Remko Popma created LOG4J2-1120:
---
Summary: LoggerConfig performance improvements
Key: LOG4J2-1120
URL: https://issues.apache.org/jira/browse/LOG4J2-1120
Project: Log4j 2
Issue Type: Improvement
No, Go for it!
Ralph
> On Sep 12, 2015, at 9:53 PM, Remko Popma wrote:
>
> Understood, so you would not want to remove the first example. Would you
> object to moving the section on the new Configuration Builder API to the top
> of the page to make it more prominent?
>
> On Sun, Sep 13, 2015
Understood, so you would not want to remove the first example. Would you
object to moving the section on the new Configuration Builder API to the
top of the page to make it more prominent?
On Sun, Sep 13, 2015 at 1:19 PM, Ralph Goers
wrote:
> Well, I view the first example as a valid use case. S
Yes, especially AbstractConfiguration.stop() has changed a few times since
AsyncLoggers were introduced.
LoggerConfig.waitForCompletion() predates those changes; that would explain
it.
On Sun, Sep 13, 2015 at 1:23 PM, Ralph Goers
wrote:
> I would have to go back and look at the code again. I re
[
https://issues.apache.org/jira/browse/LOG4J2-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742340#comment-14742340
]
Remko Popma commented on LOG4J2-124:
Yes, I think that would be good. Having the shutd
[
https://issues.apache.org/jira/browse/LOG4J2-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ralph Goers reassigned LOG4J2-124:
--
Assignee: Ralph Goers
> Gracefully stopping LogContext using the api interfaces
> -
[
https://issues.apache.org/jira/browse/LOG4J2-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742337#comment-14742337
]
Ralph Goers commented on LOG4J2-124:
What are we doing with this? Do we want to modify
I would have to go back and look at the code again. I remember having to
implement that to shutdown properly but I suppose things could have changed
since then.
Ralph
> On Sep 12, 2015, at 9:12 PM, Remko Popma wrote:
>
> Looking at this some more, I now wonder why LoggerConfig.clearAppenders
ConfigurationBuilder builds a complete configuration. So no, it cannot modify
the current configuration. I suppose it would be possible to create a new
ConfigurationBuilder from the current configuration and then edit it, but that
would require a very different API than what is currently implem
Well, I view the first example as a valid use case. Some folks might want to
allow for a flexible configuration using XML but make sure there are a few
configuration elements that are always present that can’t be removed.
Of course, we might be able to solve that by addressing LOG4J2-494 and add
Looking at this some more, I now wonder why LoggerConfig.clearAppenders()
even needs to wait for completion:
LoggerConfig.clearAppenders() is only called from
AbstractConfiguration.stop(), and is called *after* all appenders have been
stopped...
Could we do away with the waitForCompletion() method
Thanks for bringing this up. Now that we have a configuration builder API
that is just as powerful and flexible as XML configuration, we should
advertise this as THE main way for users to programatically configure
Log4j.
The Custom Configuration manual page ("Extending Log4j Configuration" in
the
If Matt wants to replace the factory methods with builders I am ok with that. I
have no interest in doing the work myself.
I am hoping to start the release process for 2.4 tomorrow. I see no blockers.
Ralph
> On Sep 12, 2015, at 4:06 PM, Gary Gregory wrote:
>
> So here we are WRT programmati
Ralph, yes, pull up the shutdown.get() check into afterLogEvent():
Gary, I expect some improvement, although it may not be huge. It should
also be visible in a single-threaded case. I hope small changes like this
allow us to catch up or exceed Logback in synchronous logging scenarios.
On Sunday,
[
https://issues.apache.org/jira/browse/LOG4J2-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14742271#comment-14742271
]
Ralph Goers commented on LOG4J2-969:
I think this can be closed. The "fix" is to just
And this will make logging faster because there is less locking in
multi-threaded apps?
Gary
On Sat, Sep 12, 2015 at 1:10 PM, Ralph Goers
wrote:
> Are you talking about making this change in signalCompletionIfShutdown()?
> If so I am OK with what you are proposing.
>
> Ralph
>
> > On Sep 12, 20
So here we are WRT programmatic configuration, users' options are:
- The new builder API. Most flexible, not 100% type-safe, a typo in a
property name can mess you up.
- The sprinkling of Builder classes. Easy to code against (fluent),
type-safe, a bit brittle but less so than factory methods (ord
Are you talking about making this change in signalCompletionIfShutdown()? If so
I am OK with what you are proposing.
Ralph
> On Sep 12, 2015, at 11:19 AM, Remko Popma wrote:
>
> I want to run this by you:
>
> LoggerConfig currently always takes a lock after logging a log event.
> Within this
I want to run this by you:
LoggerConfig currently always takes a lock after logging a log event.
Within this lock it checks if the shutdown flag has been set.
Can we do it the other way around? First check if the shutdown flag has
been set and then take the lock (to notify the other thread)?
I th
I believe one of the unit tests generated them. I believe it is the number of
nanoseconds per comparison. Logback has a lot of lock contention in its filter
processing.
Ralph
> On Sep 11, 2015, at 10:18 PM, Remko Popma wrote:
>
> Ralph, do you know what the numbers in the Advanced Filtering s
20 matches
Mail list logo
