Hi Staffan, > Thanks for the feedback! > > It is going to be hard to find the right balance between a system that > provides great power and one that is simple to use and to implement. In > general, I will lean more towards making it simple, but I want to make sure > we cover the major use cases as well.
agreed, levels is brain dead simple but at the same time.... it is brain dead.. where as tag based systems might be a bit more difficult to admin... but I would argue that they are also simple and certainly more powerful. > > It looks like there are three possible ways to select log messages being > discussed here. I'd like to discuss how to solve your problem for each one. > > 1) Selection based on component/level. (This is what is described in the JEP.) > In this case we can have any number of components. So we can have gc and > tenuring as different component. They will each have a level associated with > them. However there is no relationship between the gc and the tenuring > component, so to enable both you need to say -Xverbose:gc,tenuring. To only > enable tenuring you can say -Xverbose:tenuring. To enable all gc messages, > except tenuring you say -Xverbose:gc. This is great start on the path to tag based logging > > 2) Selection based on component/level where the component is a hierarchy. > In this case the different steps in the hierarchy can have different levels > associated with them, but if there is no explicit level associated, the > parent level will be used. So to enable both tenuring and gc you would say > -Xverbose:gc. To enable only gc you would say -Xverbose:gc,gc.tenuring=none > (I made up the 'none' level). To enable only tenuring you would say > -Xverbose:gc.tenuring. And this is where things jump the rails IMHO. > > 3) Selection based on tags. > In this case log messages are associated with a set of tags instead of a > component/level tuple. You select messages by specifying tags you want to > see. I imagine that in this case the tenuring messages would be tagged with > both the gc and the tenuring tags, but that there would be other messages > tagged with gc only. To enable gc and tenuring you would say > -Xverbose:gc,tenuring. To enable all gc messages you say -Xverbose:gc. There > is no way to see only gc messages without seeing the tenuring messages. If would be unfortunate if there was no way to see only GC messages without having to eat the tenuring records. As described this isn't a tag system, or an aspect oriented log system, it's still levels. I guess it would be good to have connivence tags that turned on a bundle of other tags. that way people who like error, warning, info fine, finner and finest can have it that way. Where as those that want to turn on logging for a particular aspect can just get to those messages. This makes more sense for GC logging but I think it also makes more sense for HotSpot also. In that environment there are things that I might only want at a debug level but if I turn on a debug level log I might get a ton of other unintended stuff with it. If I can specify a tag (like I can currently do with the current set of JVM flags) then I can get the data I need. I see this level of granularity somewhat important given that I often have to dig into production environments where everyone is very sensitive to the possible latency that maybe induced. It's often very comforting to say I can turn this on, we get this small amount of data that is very relevant to the problem at hand without flooding the system with tons and tons of messages that simply take up disk bandwidth and disk space. > > Is this a fair description of the different ways? I'm especially interested > in the last one - I'm not sure I captured your idea correctly there. Hopefully this last description fixes things ;-) Cheers, Kirk
