Elastic APM Standalone attach | ERROR Unable to attach to JVM with PID

Hi,

I’m trying to instrument a Jboss module with the elastic apm standalone attach (version 1.22)

I got this error

2021-04-08 09:20:09.379  INFO Attaching the Elastic APM agent to 86341 /opt/software/jboss/jboss-modules.jar -Djboss.modules.system.pkgs=com.sun.java.swing -Dlogging.configuration=file:/opt/software/jboss/bin/jboss-cli-logging.properties with arguments {service_name=batch-runner, server_url=http://localhost:8200}

2021-04-08 09:20:11.113 ERROR Unable to attach to JVM with PID = 86341

java.lang.IllegalStateException: Error during attachment using: co.elastic.apm.attach.bytebuddy.agent.ByteBuddyAgent$AttachmentProvider$Compound@244038d0

        at co.elastic.apm.attach.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:613)

        at co.elastic.apm.attach.bytebuddy.agent.ByteBuddyAgent.attach(ByteBuddyAgent.java:273)

        at co.elastic.apm.attach.ElasticApmAttacher.attach(ElasticApmAttacher.java:170)

        at co.elastic.apm.attach.RemoteAttacher.onJvmStart(RemoteAttacher.java:131)

        at co.elastic.apm.attach.RemoteAttacher.attachToNewJvms(RemoteAttacher.java:114)

        at co.elastic.apm.attach.RemoteAttacher.main(RemoteAttacher.java:92)

Caused by: java.lang.reflect.InvocationTargetException

        at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)

        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

        at java.lang.reflect.Method.invoke(Method.java:497)

        at co.elastic.apm.attach.bytebuddy.agent.Attacher.install(Attacher.java:110)

        at co.elastic.apm.attach.bytebuddy.agent.ByteBuddyAgent.install(ByteBuddyAgent.java:608)

        ... 5 more

Caused by: java.lang.NumberFormatException: For input string: ""

        at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)

        at java.lang.Integer.parseInt(Integer.java:592)

        at java.lang.Integer.parseInt(Integer.java:615)

        at co.elastic.apm.attach.bytebuddy.agent.VirtualMachine$ForHotSpot.checkHeader(VirtualMachine.java:277)

        at co.elastic.apm.attach.bytebuddy.agent.VirtualMachine$ForHotSpot.load(VirtualMachine.java:365)

        at co.elastic.apm.attach.bytebuddy.agent.VirtualMachine$ForHotSpot.loadAgent(VirtualM

[raphw]

By default, Byte Buddy should already consider all approaches and only consider the first that seems to work. I thought about iterating them explicitly (make an install attempt with any strategy until one succeeds) but felt that this should typically be done by the user with logging opportunity. Let me think about making retrial the default. It would require some refactoring in the internal API.

I’d suggest just that: Attempt a regular attachment, use the emulation if it does not work. The advantage with the regular attachment is that it follows the VM version while emulation can lag behind when new versions of the JVM are released.

[WassimDhib]

@SylvainJuge I can give it a try