[jira] [Commented] (LOG4J2-585) Markers not as powerful as slf4j

["Ralph Goers (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13954714#comment-13954714 ] 

Ralph Goers commented on LOG4J2-585:
------------------------------------

The choice to make Markers immutable and not support multiple parents in Log4j 2 was deliberate on my part.

Because Markers in SLF4J are mutable they suffer from performance bottlenecks with multiple threads. If you look at https://github.com/qos-ch/slf4j/blob/master/slf4j-api/src/main/java/org/slf4j/helpers/BasicMarker.java you will see that many of the methods are synchronized, in particular the contains() method.  This method is called every time you filter on a marker.  If you have an exact match it might not be so bad since it will exit very quickly, but if you are comparing against parents every comparison loops while synchronized and calls the contains method recursively.

I can tell you from personal experience that this exact scenario showed up in one of my production systems as the major performance bottleneck in the application, which is why I decided to implement it this way.

> Markers not as powerful as slf4j
> --------------------------------
>
>                 Key: LOG4J2-585
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-585
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: API
>    Affects Versions: 2.0-rc1
>            Reporter: Bruce Brouwer
>
> Log4J's markers are not as flexible as markers in SLF4J. 
> First, SLF4J's markers are mutable. By allowing markers to be mutable, I can change the relationship of markers to each other based upon runtime or business conditions. 
> Second, and more importantly I think, is that essentially SLF4J markers have this parent/child relationship, much like Log4J, except that in SLF4J, I can essentially have a marker with multiple parents. For example, I might want this structure:
> * Animal
> ** Bird
> *** Duck
> ** Mammal
> *** Bear
> *** Dolphin
> * Travels by
> ** Water
> *** Duck
> *** Dolphin
> ** Land
> *** Duck
> *** Bear
> ** Air
> *** Duck
> Of course, this is a contrived example, but I wanted to describe the relationships. Now, if I wanted to filter based on markers that travel by Water for some appenders, and another appender wants to filter by Mammals, I can't simply use the single marker of Dolphin. 
> Either we need to reverse the marker relationship so that it contains its children, much like SLF4J, or we allow markers to have multiple parents, which I prefer because it could make it more succinct to define:
> {code}
> private static final Marker BY_LAND = MarkerManager.getMarker("BY_LAND");
> private static final Marker BY_WATER = MarkerManager.getMarker("BY_WATER");
> private static final Marker DUCK = MarkerManager.getMarker("DUCK", BY_LAND, BY_WATER);
> {code}
> As for the Marker API, we would either need to change getParent to getParents, or get rid of the getParent method from the API and just rely on the isInstanceOf method to handle checking multiple parents by looking at private member variables (my preference)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org