NIFI-13865: Enable the JVM to record a heap dump when an OOM error occurs
Summary
NIFI-13865. This PR adds the following arguments to bootstrap.conf for the NiFi JVM to enable taking a heap dump when an OutOfMemoryError occurs. I'm not sure about the feasibility of unit/integration testing
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking
- [x] Apache NiFi Jira issue created
Pull Request Tracking
- [x] Pull Request title starts with Apache NiFi Jira issue number, such as
NIFI-00000 - [x] Pull Request commit message starts with Apache NiFi Jira issue number, as such
NIFI-00000
Pull Request Formatting
- [x] Pull Request based on current revision of the
mainbranch - [x] Pull Request refers to a feature branch with one commit containing changes
Verification
Please indicate the verification steps performed prior to pull request creation.
Build
- [x] Build completed using
mvn clean install -P contrib-check- [x] JDK 21
Licensing
- [ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
- [ ] New dependencies are documented in applicable
LICENSEandNOTICEfiles
Documentation
- [ ] Documentation formatting appears as expected in rendered files
This needs testing in real world deployments before it becomes an always on default. We've used this many times in the past but there was always some reason to avoid it being there as a default.
Makes sense, I'll add them commented out with some doc
good idea @exceptionfactory. In general getting our out of the box files simpler/less options and then documenting how to do things would yield a better user experience.
I can add it to the Admin Guide too, but for folks supporting other NiFi users, it just seems easier to ask the user(s) to uncomment a couple of existing lines vs having them search in the Guide for something that they might not know they're looking for, mis-copying the text from the Guide, etc.
I can add it to the Admin Guide too, but for folks supporting other NiFi users, it just seems easier to ask the user(s) to uncomment a couple of existing lines vs having them search in the Guide for something that they might not know they're looking for, mis-copying the text from the Guide, etc.
I agree this is a fine line, but over the years, the default configuration files have grown to include lot of commented information and many defaults that rarely change. In this case, the security implications and potential disk utilization concerns surrounding heap dumps make me think this should not be included in the default bootstrap.conf, even as a commented option.
It is also worth noting that the while the default configuration files should be minimal, nothing prevents others from providing alternative defaults in customized packages. The goal of the default files, however, should be to provide sensible and secure defaults without overwhelming users.
I was using the debug and javaAgent entries as an example.
I agree the debug and javaAgent examples are notable. There are other common production-level options we could consider, such as maximum directory memory usage, and other memory settings, but these are more specific to given environments, and harder to generalize. That's where having a section of the Admin Guide, with copyable examples, seems like a better way to go more for more JVM options.
Ok I will change this PR/Jira to add this to the Admin Guide instead
Due to comments about the nature of this PR subject to change going to close for now. Please open a new one as available.