NPE when connecting to native image about cryostat-core HOT 13 CLOSED

The OpenShift part should not affect this code pathway, this should be fully reproducible locally with ex. the Cryostat smoketest.sh script.

What's happening is that when Cryostat discovers a JVM, it tries to connect to that JVM and hash some MBean attributes to generate a fingerprint ID of that JVM. It uses this fingerprint when doing things like storing archived recordings for that JVM, so that if you have two or more different URLs that resolve to the same actual JVM process, you can see the same data across those different URLs.

from cryostat-core.

The -agent also goes through this same code pathway when it's figuring out its fingerprint ID which it publishes to Cryostat when it does its discovery updates, so fixing this bug in -core will fix the problem on both sides.

from cryostat-core.

Yep, that's what I thought when I was originally working with Janelle to implement this hashing technique. I don't think the JVM generally has any exposed unique ID like this, at least not one that we can retrieve over JMX/MBean. Even the PID isn't likely to be helpful in containers.

I wonder if the hostname or primary interface IP can be pulled from somewhere?

from cryostat-core.

Otherwise, if this is not fully solvable in the case where Cryostat determines the fingerprint ID by connecting to the JVM over JMX, it's still solvable in the case where the Agent is present and determines its own ID to publish to Cryostat. We can just forego the whole MBean attribute collection stuff there and simply generate a UUID. This could be a technical reason for users deploying very horizontally scaled applications to use the Agent, rather than the classic Cryostat+JMX.

from cryostat-core.

@roberttoyonaga are there any other MBean attributes you think would make sense to add in to that hash? We could simply skip anything that is null and cannot be retrieved in cases like SubstrateVM, and then check that the DataOutputStream is not empty before hashing it (and throw some informative exception if it is empty), but I worry that eliminating too many of these attributes may lead to hash collisions in practice because there just isn't enough input differentiation.

from cryostat-core.

are there any other MBean attributes you think would make sense to add in to that hash

Hmm maybe you could try OperatingSystemMXBean.Arch, OperatingSystemMXBean.Name, RuntimeMXBean.Pid, RuntimeMXBean.SpecVersion, RuntimeMXBean.VmName. I just tried these out on quarkus native connecting with JMC. These are all non-null and constant for the life of the process in SubstrateVM.

from cryostat-core.

Also, RuntimeMXBean.StartTime is implemented for SubstrateVM (and you already include that in the hash). So that should be a big help in differentiating between "JVMs"

from cryostat-core.

Yea, that's one of the key ones for sure, though it's "only" millisecond resolution and so I wonder if it can still be a problem in a container orchestration environment where a deployment is scaled up and several replicas are started. I suppose it depends heavily on the cluster/node doing that work, but might more than one container come up with the same millisecond timestamp? Hmm.

from cryostat-core.

Right, that's a good point. In that sort of scenario most of the other attributes will be shared as well :(

from cryostat-core.

I wonder if the hostname or primary interface IP can be pulled from somewhere?

Not sure about this. Off the top of my head I haven't seen anywhere this might be accessible via RJMX.

from cryostat-core.

By skipping attributes that are null, I am able to see the GraalVM native image in the topology view. However, a new error presents itself after selecting it as the target in the recordings view:

from cryostat-core.

I think there should be a longer/more informative corresponding stack trace in the Cryostat server logs when that happens. Could you post it here as well?

from cryostat-core.

Actually, you could post that in the PR you've opened.

from cryostat-core.