That's good to hear! A lot of people still use SLF4J with Log4j 2, so anything that makes them more performant is a nice bonus.
On 23 February 2017 at 21:29, Apache <ralph.go...@dslextreme.com> wrote: > I tested SLF4J after the fix and on my computer the performance problem > does seem to have been addressed and the code should now be thread safe. > > Ralph > > > On Feb 23, 2017, at 2:39 PM, Apache <ralph.go...@dslextreme.com> wrote: > > > > And that issue has now been marked closed. However, there are still a > couple of synchronized methods in there that are called on every filter > comparison so we will have to rerun our performance benchmarks to see if it > made a significant difference. > > > > Ralph > > > >> On Feb 23, 2017, at 2:30 PM, Apache <ralph.go...@dslextreme.com> wrote: > >> > >> Ceki obviously reads this list as he marked SLF4J-240 in progress right > after I posted the message below. Keep an eye on that for a fix. > >> > >> While your in there Ceki, the contains methods in BasicMarker aren’t > thread-safe. > >> > >> Ralph > >> > >>> On Feb 23, 2017, at 1:29 PM, Apache <ralph.go...@dslextreme.com> > wrote: > >>> > >>> Markers would work but I wouldn’t recommend using them with SLF4J. See > https://jira.qos.ch/browse/SLF4J-240 <https://jira.qos.ch/browse/SLF4J-240>. > It has been open for over 5 years so I’m of the impression it will never be > fixed. http://logging.apache.org/log4j/2.x/performance.html# > Advanced_Filtering <http://logging.apache.org/log4j/2.x/performance.html# > Advanced_Filtering> shows that filtering on Markers becomes a huge > bottleneck in a multithreaded system. > >>> > >>> Ralph > >>> > >>> > >>>> On Feb 23, 2017, at 1:01 PM, Marshall Schor <m...@schor.com> wrote: > >>>> > >>>> > >>>> > >>>> On 2/23/2017 1:09 PM, Apache wrote: > >>>>> You shouldn’t be trying to modify the logger. You should be trying > to modify the configuration. Take a look at http://logging.apache.org/ > log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_ > Configuration_after_Initialization <http://logging.apache.org/ > log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_ > Configuration_after_Initialization> <http://logging.apache.org/ > log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_ > Configuration_after_Initialization <http://logging.apache.org/ > log4j/2.x/manual/customconfig.html#Programmatically_Modifying_the_Current_ > Configuration_after_Initialization>>. That example creates an appender > and a logger and adds them. In your case, you would want to find > loggerConfig associated with your logger by calling > config.getLoggerConfig(“loggerName”). > Then add the filter to that. > >>>>> > >>>>> That said, you should probably explain what you are actually trying > to do. More often than not, dynamically updating the logging configuration > is unnecessary as what you really want to do can be achieved other ways. > >>>> > >>>> Thanks. > >>>> What I'm trying to do is to run JUnit testing of an old logging > facade that I've > >>>> bridged to log4j-2. > >>>> > >>>> In the test, I set a filter, and want to see that it worked. > >>>> > >>>> While I have your attention, I'm bridging from a format that used the > JUL > >>>> "CONFIG" level, and would like to know how to represent this in a > "neutral" way > >>>> for modern loggers. (I'm thinking of SLF4J, Log4J, and LogBack). My > thought is > >>>> to map CONFIG requests to INFO requests with a "Marker" identifying > CONFIG. > >>>> Same goes for FINE/FINER - mapping to TRACE, with markers for the two > >>>> alternatives. To make this work, I'm implementing special "Filters" > :-). > >>>> > >>>> Is there a better way? I know you can introduce additional levels in > Log4j-2, > >>>> but that doesn't seem to be supported in SLF4J and LogBack, and I'm > looking for > >>>> a more universal approach. > >>>> > >>>> Thanks. -Marshall > >>>> > >>>>> > >>>>> Ralph > >>>>> > >>>>>> On Feb 23, 2017, at 9:39 AM, Marshall Schor <m...@schor.com> wrote: > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I'm writing test cases, using version 2.8 of Log4j. > >>>>>> > >>>>>> One test sets a filter on a logger. > >>>>>> > >>>>>> Looking (afterwards) at the logger, I see that the logger has a > field: > >>>>>> > >>>>>> "privateConfig", and that has two fields for configuration info: > >>>>>> > >>>>>> - config (set to an instance of XmlConfiguration) > >>>>>> - loggerConfig (has the filter I set on the logger). > >>>>>> > >>>>>> The code for isEnabled in Logger (line 238): > >>>>>> public boolean isEnabled(final Level level, final Marker marker, > final Object > >>>>>> message, final Throwable t) { > >>>>>> return privateConfig.filter(level, marker, message, t); > >>>>>> } > >>>>>> > >>>>>> privateConfig.filter() although it has both a "config" and a > "loggerConfig", > >>>>>> only checks the config. > >>>>>> > >>>>>> The fact that I successfully used an API to set the loggerConfig > with a filter > >>>>>> is ignored. > >>>>>> > >>>>>> Should the design for privateConfig.filter() check both configs, or > is there > >>>>>> some API call to "merge" the change I did that was recorded in the > field > >>>>>> "loggerConfig" into the config stored in the field "config"? > >>>>>> > >>>>>> -Marshall Schor > >>>>>> > >>>>>> P.S., here's the API call I did to set a filter: > >>>>>> > >>>>>> // coreLogger is a cast of a normal logger, to enable the get() > method > >>>>>> coreLogger.get().addFilter(myFilter); > >>>>>> > >>>>>> // not sure if this is needed, but did it anyways > >>>>>> coreLogger.getContext().updateLoggers(); > >>>>>> > >>>>>> > >>>>>> > >>>>>> ------------------------------------------------------------ > --------- > >>>>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > >>>>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >>>>>> > >>>>>> > >>>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > <mailto:log4j-user-unsubscr...@logging.apache.org> > >>>> For additional commands, e-mail: log4j-user-h...@logging.apache.org > <mailto:log4j-user-h...@logging.apache.org> > >> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > >> For additional commands, e-mail: log4j-user-h...@logging.apache.org > >> > >> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > -- Matt Sicker <boa...@gmail.com>
