Proposal: Option to ignore non-existent -javaagent

Jaroslav Bachorik j.bachorik at gmail.com
Sun Jul 14 15:56:02 UTC 2024


On Fri 12. 7. 2024 at 21:06, Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > On 10 Jul 2024, at 16:37, Jaroslav Bachorik <j.bachorik at gmail.com>
> 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,
>
> A pragmatic solution of one problem is often — as in this case — the cause
> of other problems. A Java application may happen to run, by chance, with
> some classes or an agent missing, or it may not, which may manifest in a
> strange way.
>
> In order to better judge the pros and cons, can you please explain in as
> much detail as could be relevant, the difficulties involved in having
> different runtime scripts and/or a conditional in the script? This would be
> at least as pragmatic a solution, so to compare the two we need to
> understand why a script can be so difficult to write or change as to
> necessitate a change to the JDK. Going from “my startup script is not very
> flexible” to “so let’s change the JDK” is a big jump that would require a
> big justification.


I have unwittingly became the advocate for this change although I really
don’t care at this moment.  I just thought to bring up my painful
experience when I had to deal with Yarn (clustering solution) and Apache
Spark.
You can read more about that at
https://spark.apache.org/docs/latest/running-on-yarn.html#spark-properties -
I am not going to transcribe all of that here.

The bottom line is that the clustering solution allows specifying JVM
options and extra resources that will be distributed to all nodes. Hence,
if you want to add an agent, you need to add the jvn options to point to
the location where the agent jar (resource) will be placed.  As you can
expect, things can break and you end up killing your Spark pipeline instead
of running without observably 🤷‍♂️

However, I don’t understand the argument that running without agent can
lead to subtle errors. Agents were always meant to be optional - the core
application functionality should not really be dependent on the agent
availability. But, obviously, I was wrong all this time.

-JB-


>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20240714/5a5c8058/attachment-0001.htm>


More information about the serviceability-dev mailing list