> I was reading that email and was thinking of JVM debug options, with > suspend y/n. I guess it just shows we meant very different things by debug > mode. Maybe you could incorporate those into a PR too? > > Andrew
Good point Andrew. and sorry for the slow response. I had to look at how NiFi set the JVM properties. We had issues with Java and needed to manually set env Java flags. It seems all of the Java debugging flags are set in the bootstrap.conf, located here. https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-resources/src/main/resources/conf/bootstrap.conf For me, I chained together the Dockerfile ENTRYPOINT ["my_company_entry_point.sh"] then had it call the original entry point In short, all of NiFi properties are set via environment variables in a /etc/profile.d/nifi.sh on the host and propogate throughout the NiFi system. Like I listed in https://github.com/dprophet/nifi/blob/master/nifi-docker/dockerhub/CONFIGURATION.md I normalized all NIFI specific environment variables to start with NIFI_ Why? Because you set the export NIFI_FOO="my foo" and its directly passed into the container and into the NiFi role account used to start the container. You now have access to the environment variables throughout the NiFi system. Example: docker run --name nifi --env-file <(env | grep NIFI_) --hostname nifi IMO, the Dockerfile entry point should allow a plug and play script so you can set these custom behaviors (both enterprise behaviors and custom developer/debugging). I doubt any enterprise will blindly pull a DockerHub container and run it. From my experience, a public container isnt enterprise friendly. Andrew, define what you want for JVM debugging, what you would want to set (and unset), and I will take a look. Erik Anderson Bloomberg https://www.linkedin.com/in/erikanderson/
