Yeah, but it makes me wonder if anyone is using Markers. That bug was found over 5 years ago during performance testing of an app at my former employer when they were still using Logback. It received no votes in Jira and no one saying “me too”. If they were doing any kind of logging with the MarkerFilter in the configuration they would have noticed the problem during any performance testing.
That said, I too am glad it is finally fixed. But between that and the improvements to the FileAppender we need to update the performance page. In my tests we are still coming out ahead but Logback is now much better than it was. Ralph > On Feb 23, 2017, at 8:33 PM, Matt Sicker <boa...@gmail.com> wrote: > > 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> --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
