Open zhoufenqin opened 1 year ago
If the options to enable flight recorder are the same for native image, we could add the JFR helper for it too. If they are not the same, we'd need a new helper.
Great, thanks @dmikusa , I think it's different and the buildpack won't be put into runtime image /layers.
I think it's a general feature, some other features may also request for this. Like supporting heapdump also need a helper.
BTW, what are the plans for adding features to the buildpack? E.g. how long will the feature be realized?
BTW, what are the plans for adding features to the buildpack? E.g. how long will the feature be realized?
There is no roadmap like with a traditional product that you'd purchase. It's an OSS project, so it really depends on when someone that is interested in this feature contributes the code.
Env: kpack 0.9.2 k8s
If I want to enable JFR with Native Image, then in the build phase, I will pass a build argument like
BP_NATIVE_IMAGE_BUILD_ARGUMENTS="--no-fallback --enable-monitoring=jfr --enable-monitoring=jvmstat"
.In runtime, I should configure JFR
-XX:+FlightRecorder -XX:StartFlightRecording="filename=recording.jfr"
to enable JFR and start a recordingFor an pod spec, it looks like
But I hope the argument can be passed in another way. Like in OpenJDK buildpack, we will set
BPL_JFR_ENABLED = true
, then-XX:StartFlightRecording=dumponexit=true,filename=/tmp/recording.jfr
will be automatically injected into JAVA_TOOL_OPTION when starting the java process.Not sure if there are similar operations in a native image, we can pass some runtime environment, then
/cnb/process/web
will pick up some env as runtime parameters?Expected Behavior
we don't need to configure each args manually, just configure some
BPL_
env to represent the runtime environments.Current Behavior
we should define args for each native image feature
Possible Solution
Steps to Reproduce
Motivations