[
https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13954753#comment-13954753
]
Bruce Brouwer commented on LOG4J2-585:
--------------------------------------
About the performance, I suspected what Ralph is saying would be a very real
concern. I looked at the way BasicMarker is implemented and there is nothing
that requires us to extend from BasicMarker. I was playing around with an
implementation that used a ReentrantReadWriteLock. In most cases, the time
spend modifying markers is only in the startup of the app. So I agree, slapping
a synchronized on the most important methods is a huge performance bottleneck.
But with the ReentrantReadWriteLock, the major time of an application would
cause no blocking at all.
I also have some ideas on how we could get the performance of the regular Log4J
markers better than they are today at the expense of a little bit more memory.
Also, if we made the Log4J markers mutable, then we could have the SLF4J
implementation simply delegate to the real Log4J markers. Right now, the two
are completely separate. If you have code that mixes Log4J markers with SLF4J
markers (because of some 3rd party library that uses SLF4J) the hierarchies can
be completely different. This is probably not what people would expect to have
happen. I think it will also have real issues when used with the MarkerFilter,
which would be referencing a real log4j Marker while comparing against an SLF4J
marker.
Another thing that I noticed is that I think the SLF4J implementation is
broken. SLF4J intends the pointers to be pointing at the children. Log4J
intends the pointers to be to the parent. Because of this, the implementation
of MarkerWrapper.isInstanceOf is backwards.
I would like to fix this immutability issue, but the issue of allowing multiple
parents I think more important, and one that is easy to fix. Would I have
support of changing these things if I submitted a patch? Especially if I took
careful consideration for performance issues?
> 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-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
