Hi all
On 2014-05-18 12:14, Kirk Pepperdine wrote:
Hi Fredrik,
I do need more information but I think a flat structure would provide less
overhead rather than passing messages through a network of “sub” loggers.
Kirk, I can understand that you are concerned that the hierarchical
structure would create unnecessary overhead, but it does not have to.
With a good implementation design messages does not have to be passed
through any other logger than the one it is logged to. I wont go in to
any details here, but in my current poc implementation I think the code
is quite efficient, even if I don’t have spent that much time on
optimization yet. I think that having a good design that answers well to
the requirements is better than doing premature sub optimization by
crippling the design. Functionality first, optimization later, that's
how I like to do it.
I will do my best to spend some time looking at Peters code, I am sure
there are good things in there to consider.
Cheers
/Fredrik
Peter Lawrey wrote JChronicle which at it’s core is a messaging system but it’s
also a wickedly fast logger. That said, there isn’t a formalized logging
interface to it though it’s something being discussed/thought about as we speak.
https://github.com/peter-lawrey/Java-Chronicle.
I’m not suggesting you take this implementation but there might be things to
learn from it as this spec is being strengthened.
Kind regards,
Kirk Pepperdine
On May 18, 2014, at 11:47 AM, Richard Warburton <richard.warbur...@gmail.com>
wrote:
Hi Fredrik,
In the JEP I tried to explain the concept of 'sub' loggers but I did not
put in anything about the intent of having them. I think that your
requirement easily could be solved using sub loggers, or sub components if
you like that wording better.
Loggers are ordered in an hierarchical tree where 'gc' might be the root
for all logging in the gc 'area'. The 'details', 'cause' and 'safepoint'
content types could be translated in to sub loggers to the 'gc' logger. By
setting log level for the separate sub loggers to enable logging I cant see
that you would not be able to get the filtering you want. By using log
levels wisely you will be able to get even more control over what gets
output in the logs. The above was a much simplified example, in reality you
would probably have a more elaborate tree of gc loggers. There is nothing
in the logger three hierarchy approach that implies that they should be big
blocks of stuff.
Logging topics, tags, or markers were something we considered at the
beginning of the design phase but we came to the conclusion that we
probably could solve the requirements by using sub loggers instead.
Please tell me if you don't think this approach would work, and in that
case why.
Thanks for clarifying this point. I think this explanation addresses how
that particular use case is met. I suspect that it might be worth adding a
bit more explanation around this topic to the JEP itself, because I don't
think I'm the only person with this concern.
Also a heads up that there's discussion happening related to this topic
off-list at:
https://groups.google.com/a/jclarity.com/forum/#!topic/friends/NA0EyOJk6bs
regards,
Richard Warburton
http://insightfullogic.com
@RichardWarburto <http://twitter.com/richardwarburto>
