Proposal: Option to ignore non-existent -javaagent

Jaroslav Bachorik j.bachorik at gmail.com
Fri Jul 12 15:19:04 UTC 2024


On Wed, Jul 10, 2024 at 5:53 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 10/07/2024 16:37, Jaroslav Bachorik wrote:
>
> :
>
> This may not always be possible. Some systems have rather complex and
> inlexible launchers - for example Apache Spark with its clusters, drivers
> and executors and automatic distribution of resources. For that system, if
> one needs to add an on-startup Java agent via `-javaagent` option the only
> way is to modify the setup which will add `-javaagent` to all components,
> pointing to a location where the resource distribution service should be
> putting the agent jar. However, mistakes happen and the jar may not be
> there. But  because usually the agent is providing tracing or metrics
> collection, which are all optional, it is not feasible to hard-crash the
> Java process because of not being able to load the Java agent.
>
> Forn this PoV the proposal to allow optionally ignoring non-existing Java
> agent sounds as a very pragmatic solution,
>
>
> The issue of injecting CLI options to start tool agents was explored back
> in JSR 163, that is the reason for environment variables such as
> JAVA_TOOL_OPTIONS. Broader support was added in JDK 9 with
> JDK_JAVA_OPTIONS, @argfile support, and support for GNU style options. So
> the JDK has several features to augment the command line or options.
>
> Has anyone tried to work with the Apache Spark (or other projects) to make
> use of any of this support so that additional CLI options are conditionally
> used?
>

I might have not been completely clear about this use case. The problem is
that the agent must be distributed to each node of the cluster and if, for
whatever reason, there is an issue with the process or the there is a typo
in the path of the agent specified in the launcher arguments, JVM will
hard-fail, which is quite a steep price to pay.

I fail to see how JAVA_TOOL_OPTIONS, JDK_JAVA_OPTIONS or @argfile would
help here - the agent location would always be statically defined and hence
prone to crash JVM if the agent is not at the expected location. The only
way I can imagine this could work would be for eg. Spark (or any other
service affected by the mismatch of the configuration and the agent file)
to have a special 'agent' configuration in the launcher which would then be
dynamically translated into `-javaagent:` JVM argument, given that the
agent file is accessible.

TBH, I have no stakes in this any more - it's just I've always found
crashing on missing java agent rather baffling experience.

-JB-


>
> -Alan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240712/bc5432d0/attachment.htm>


More information about the serviceability-dev mailing list