<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2024 at 5:53 PM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com">Alan.Bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
  <div>
    On 10/07/2024 16:37, Jaroslav Bachorik wrote:<br>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr">:<br>
        </div>
        <div class="gmail_quote">
          <div><br>
          </div>
          <div>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.</div>
          <div><br>
          </div>
          <div>Forn this PoV the proposal to allow optionally ignoring
            non-existing Java agent sounds as a very pragmatic solution,</div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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?<br></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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. <br></div><div><br></div><div>TBH, I have no stakes in this any more - it's just I've always found crashing on missing java agent rather baffling experience.</div><div><br></div><div>-JB-<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <br>
    -Alan<br>
    <br>
  </div>

</blockquote></div></div>