On Fri, 2014-05-16 at 11:45 +0100, Richard Warburton wrote: > Hi, Hi all,
I share this same doubts, and I'm also a bit confused. > I'm not saying that an abstract framework should depend upon the details of > the different components but if you had component definable markers for the > type of information in order to offer more fine grained control I think it > would be a most appreciated. That way something like a GC logger could > define its own markers for details, cause, application stopped time, > safepoints etc. An end user who is trying to diagnose a specific problem > could leave their gc logger at warning, but also then has the option to > enable a specific marker for something like application stopped time which > is probably a lower level than warning. This would be very nice. I think this JEP pretty much works in the same direction as 167. I believe the ultimate goal should be to have some kind of DTRACE/STAP feature where user could enable/disable a specific probe/set of probes at runtime and get events from those, while JVM/Serviceability developer could easily add probes and instrumentation to the code in a standard way with a proper structure (which should be efficient also). If I understand correctly, this JEP tries to implement the logging part of such infrastructure (as you say in Non-Goals). I would not do this, though: "Logging messages are in human-readable plain text" This should be part of the logging backend, which may be part of the framework and so still be a goal in a sense, but I would rather keep it separated from the logging infrastructure itself, which is what I would spend more time defining. Looks to me that the concept of adapters is very interesting, but applies to the "act of logging" itself. For instance, if you log a thread state change event, this would end up in the adapter, whose job is to put it, say, in a file, rather than in the syslog, etc. I would go a bit further though, defining a specific protocol where those events are accumulated before being consumed by the adapter, this protocol should allow for minimum overhead, for instance, all events will be directed to a memory buffer, a separate adapter thread will read this buffer and take away in FIFO order, etc.. Not sure if this is part of this JEP, but sounds a more interesting and useful thing to do (I was hoping to see this in JEP 167, but apparently this is not what happens there). Cheers, Mario
