why in this place use System.exit(1)?

[zhic0223]

why in this place use System.exit(1)? Can I rm it?

[zhic0223]

@brian-brazil

[fstab]

What else would you expect to happen if you run it with illegal command line parameters?

[zhic0223]

I mean if use System.exit(1),Will using this cause the process of the application that the user mounts the jmx-exporter agent to also exit?

[fstab]

Yes. If you start the application with an illegal command line, the application exits immediately.

[zhic0223]

So I think this place is not very user friendly, is there any way to optimize it here

[dhoard]

@zhic0223 not sure what you're trying to accomplish. If you define your application to use the agent and the agent is misconfigured, allowing the application to run without the agent doesn't make sense to me.

[zhic0223]

When the agent of jmx-exporter is mounted, if the client's application is forcibly exited simply because the parameters of vm options do not conform to the specifications of jmx, I think this is unreasonable. You can only exit the agent, not the Also opted out of the client's app.

[zhic0223]

I think this part can be optimized to remind the user that the vm options parameter configured when accessing the agent is incorrect, and tell him the correct configuration method, which is more secure. You can't cut off a person's head just because he has a cold.

[dhoard]

@zhic0223 I disagree. Allowing the application to run with a misconfigured agent will most likely result in more work on the end user to debug the issue and possibly more GitHub issues... "We installed and configured the agent and the application is running, but we can't access the JMX metrics"

[zhic0223]

I disagree. Allowing the application to run with a misconfigured agent will most likely result in more work on the end user to debug the issue and possibly more GitHub issues... "We installed and configured the agent and the application is running, but we can't access the JMX metrics"

@dhoard There is a scenario that the customer's online application needs to monitor and observe the indicators of jvm for some reason, and then the customer mounts jmx, but his online application is not allowed to hang up for a long time. Then if the customer's vm options parameter is wrongly written, will the customer's online application always fail to start? What if that app has a lot of people online? If the customer's application is directly exited by jmx, the customer will never use jmx again?

[dhoard]

@zhic0223 Thanks for the use case clarification.

The agent is written assuming it will be defined as part of the JVM arguments and configured correctly. In my opinion/experience, this is the most common use-case scenario.

The code would need to be changed to support dynamic attachment correctly. (Failure of the agent doesn't cause the application to exit.) Keep in mind that attaching an agent dynamically to a running JVM requires the application to be coded to dynamically load the agent.

@fstab is dynamic loading with bad configuration a scenario the agent is expected to correctly handle?

EDIT: updated question

[dhoard]

To support correctly support dynamic agent loading (prevent misconfiguration from exiting the application when using the agent dynamically) theJmxCollector code would also need to be changed.

jmx_exporter/collector/src/main/java/io/prometheus/jmx/JmxCollector.java

Line 147 in b6b811b

exitOnConfigError();

jmx_exporter/collector/src/main/java/io/prometheus/jmx/JmxCollector.java

Line 106 in b6b811b

private void exitOnConfigError() {

[fstab]

@dhoard thanks a lot for looking into this. I agree the agent is not written with dynamic attachment in mind. There are some other issues as well, like the agent does not detach cleanly as some classes will still be referenced after detaching the agent (see prometheus/client_java#809). The recommended usage is either to attach the agent at startup and leave it attached, or to run jmx_exporter_httpserver in standalone mode and scrape JMX beans remotely via the network.

[zhic0223]

@zhic0223 Thanks for the use case clarification.

The agent is written assuming it will be defined as part of the JVM arguments and configured correctly. In my opinion/experience, this is the most common use-case scenario.

The code would need to be changed to support dynamic attachment correctly. (Failure of the agent doesn't cause the application to exit.) Keep in mind that attaching an agent dynamically to a running JVM requires the application to be coded to dynamically load the agent.

@fstab is dynamic loading with bad configuration a scenario the agent is expected to correctly handle?

EDIT: updated question

You're welcome！I hope there are more scenarios to be tested and perfected here.

[dhoard]

Dynamic attachment is not supported/working as designed.

Closing as resolved.