Hi Martijn, and the others :)
I'm glad you like what we do. We also think the tag based logging is
something good, and that it will make the logging in the JVM easier to
implement, configure and consume.
Regarding 'binary / compressed' log format. We are not planning to add
any structured log format to the unified logging framework. It is
outside the scope of this JEP. The log data format is a simple string
with some well defined decorations. The logs are primarily meant to be
read by humans.
There will be log output extension points in the framework, but they
will not be accessible publicly and they will not support 3rd party
extensions in runtime. Even if the output extension API would be made
fully accessible, the data fed in to it would still only be a string,
since thats what the developers are adding in the code where the logging
framework is called. I guess one could add compression of log data as an
extension, but I don't think that is really what you are asking for.
As you might know, Oracle offers low latency low intrusive structured
logging in its Java Flight Recorder product. We are not aiming in this
JEP to overlap that functionality more than absolutely needed.
Cheers
/Fredrik
On 2015-04-17 12:12, Martijn Verburg wrote:
Hi Fredrik,
Thanks from us (jClarity and some other orgs) for considering the tag
based system, we're really glad you've gone in this direction. One
quick bit of feedback.
Is it possible to add a binary / compressed logging format or an
interface/ API to plug one in for high performance Logging? Human
readable is nice for looking at logs immediately, but for some of our
customers they'd be looking to offload that concern to another
process/host.
Cheers,
Martijn
On 17 April 2015 at 09:32, Fredrik Arvidsson
<fredrik.arvids...@oracle.com <mailto:fredrik.arvids...@oracle.com>>
wrote:
Hi
We are planning to release an updated version of JEP-158 very
soon. The work to update this JEP has been going on for some time
and we now feel we are ready to present it to a wider audience.
The JEP for JVM Unified Logging was created back in February 2012.
The requirements for the API and implementation were heavily
influenced by the logging functionality in JRockit JVM. The JEP
was updated and refined in mid 2014 and eventually targeted for
JDK 9 in late 2014:
https://bugs.openjdk.java.net/browse/JDK-8046148
During the review process of the JEP some concerns were voiced
about the chosen API and functionality but the conclusion was that
the proposal would work, and the JEP was targeted for JDK 9 and
the implementation work was started.
Early 2015 during pre-reviews and presentations of the API and
implementation concerns were again raised about the formulation of
the JEP, this time with greater force. At this point we decided to
take a time-out and investigate our options going forward.
The time-out led to a modified proposal that can be found here:
http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158.html
<http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158.html>
and with some illustrations here:
http://cr.openjdk.java.net/~farvidsson/JEP-158/JEP-158_Illustration.png
<http://cr.openjdk.java.net/%7Efarvidsson/JEP-158/JEP-158_Illustration.png>
So what have we changed, and why?
In short we have switched from using an hierarchical log subject
layout to something that could be best described as a tag based
solution.
The main reason for the change of the logging API is that we have
found that some logging can't easily be ordered under a single
hierarchical subject but can belong to multiple subjects/areas.
One example of this is logging in the 'metaspace' code. The
functionality in the 'metaspace area' can be called from both GC
and Runtime code. Another example is class-unloading. There are
more examples on this of course, but these two we think are very
clear and easy to understand.
The core functionality of the logging framework is not changed
that much from the earlier proposal. We have tried to make it
leaner and not as verbose (functionality wise) as before. The
scope of the implementation has been narrowed down some to enable
us to deliver good value as soon as possible.
Our plan is as follows:
After getting initial feedback from the community about the new
proposal we will update the JEP description. We aim to do this
early next week.
We are planning to use the JDK9 sandbox repository during
development. This enables us who are implementing it to work in an
efficient way and at the same time it allows any interested party
to try out and follow the work during the implementation phase.
More information about the sandbox repository name and other
practicalities will follow shortly.
Cheers
Fredrik Arvidsson & Marcus Larsson, JVM Serviceability, Stockholm.
