[
https://issues.apache.org/jira/browse/LOG4J2-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961475#comment-13961475
]
Ralph Goers commented on LOG4J2-585:
------------------------------------
I spent quite a bit of time yesterday working on this and running the
benchmarks against various implementations and I think I finally came up with
something that is OK. My results are:
||Depth||Current||Multiple Parents
| 4 | 516K ops/ms | 276K ops/ms (47% slower)
| 3 | 636K ops/ms | 381K ops/ms (40% slower)
| 2 | 903K ops/ms | 451K ops/ms (50% slower)
| 1 | 1,661K ops/ms | 1,356K ops/ms (18% slower)
| 0 | 2,882K ops/ms | 2,827K ops/ms (2% slower)
I'm OK with this primarily since I expect most Markers will only be a parent or
a parent and a child.
One thing interesting to note is that your tests of the current implementation
seem to degrade much more significantly than mine. I suspect that is due to the
different machines. I am running on what is now a fairly old Macbook Pro. It
has a 2.5 GHz Intel Core i7 processor. It has 4 physical cores with 2 logical
cores per physical core.
In thinking about the immutability I have come to the conclusion that I can't
do it. If I make the relationship between Child and Parent immutable there is
nothing that would prevent the Parent from having a Grandparent added to it,
which kind of makes the whole idea pointless.
I still have to work on the SLF4J wrapper but I hope I can get it committed
today.
> 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
> Attachments: ConceptMarkerBenchmark.java,
> CurrentMarkerBenchmark.java, log4j2-585-concept.patch
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
