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
