I haven't used markers much, but I've finally figured out an interesting use case for them at work: marking log messages to filter them into a Slack message. Right now we've got people using random Slack libraries to post messages in team channels to alert various things, yet a simple appender plus marker filter would simplify this quite a bit. I'd imagine that some people use differently named loggers or other tricks because they don't know about markers in the first place.
On 23 February 2017 at 21:44, Apache <ralph.go...@dslextreme.com> wrote: > 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-help@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 > > -- Matt Sicker <boa...@gmail.com>
