[ 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: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org