Virtually all the benefits of monitoring come in production environments 
(by definition, I think), and that's probably why you don't see this 
scenario (as) commonly used with JFR.

Basically, using JFR for production [currently at least] requires a 
commercial Java SE Advanced license. How/if this is enforced technically is 
irrelevant, the click-thropiugh license that allows you to use it for free 
is specifically restricted to non-production use. This is spelled out in 
the Oracle Binary Code License Agreement for the Java SE Platform Products 
and JavaFX 
as a "Commercial Feature" (you literally have to use the 
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder to use it) it's 
impossible to claim ignorance of this fact. See e.g.,,
for some discussion and mentions around it. 

So while JFR can and may do some cool (and even semi-unique) things for 
production monitoring, you'd have to clear the commercial pricing terms 
first, and those seem pretty steep, as in a list price of $5000 per 2 x86 
cores according to the Oracle price list 
which would equate to e.g. $40K per instance for EC2 m3.2xlarge instances, 
and $80K-160K per server for modern 2 socket servers (those with "only" 
16-32 cores). While I'm sure the actual production pricing could end up 
much lower once purchasing departments finish hand-wrestling with Oracle's 
sales folks, it would probably still be way more than other commercial 
monitoring and JVM-knowledgable APM solutions that are much more feature 
rich and focused would cost (e.g. Dynatrace, AppDynamics, NewRelic, etc.), 
all of which list at a tiny fraction of the Oracle Java SE Advanced list 
price levels (and are massively used in production systems).

On Thursday, December 1, 2016 at 12:18:18 PM UTC-8, wrote:
> Hi all,
> Does anyone know a good way to do continuous performance monitoring using 
> JFR (JDK8)? I am interested in using this on some apache data pipeline 
> projects (Spark, Flink etc). I have used JFR for perf profiling with fixed 
> duration before. Continuous monitoring would be quite different.
> The ideal scenario is to set up JFR to write to UDP <ip:port> destinations 
> with configurable update frequencies. Obviously that is not supported by 
> JFR as it stands today. So I tried setting up continuous JFR with 
> maxage=30s and running JFR.dump every 30s, to my surprise the time range 
> covered by the dumped jfr files does NOT correspond to the maxage parameter 
> I gave. Instead the time ranges (FlightRecordingLoader.loadFile(new 
> File("xyz.jfr")).timeRange) from successive JFR.dump can be overlapping 
> and much bigger than maxage.
> So couple of questions for those experienced users of JFR:
> -- What exactly is the semantics of maxage?
> I imagined that maxage has 2 effects: discarding events older than maxage 
> and aggregating certain metrics (like stacktrace sample counts) over the 
> time interval. It appears my understanding was way off.
> -- How does the event pool/buffer under consideration for next JFR.dump 
> get reset?
> I was hoping every JFR.dump would reset the pool and allow the next 
> JFR.dump to output non-overlapping time range. I was also wrong here.
> -- Is there any way to do continuous perf monitoring with JFR with a 
> configured aggregation and output interval?
> One thing I did notice is that JFR would periodically (default seems 60s) 
> flush to chunk files and then rotate chunk files according to maxchunksize 
> param. I could use that mechanism to inotify-watch the repository dir and 
> just read and parse the chunk files. However there are a few things missing 
> if I wanted to go down this route: there is no way to set "maxchunkage" 
> (would like to be able to set one as low as 10s), I will need to write some 
> custom chunk file parser, not sure if chunk files have all the symbols to 
> resolve the typeids.
> Thanks!

You received this message because you are subscribed to the Google Groups 
"mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
For more options, visit

Reply via email to