cryostat-legacy
cryostat-legacy copied to clipboard
cryostatio
[Task] Aliased target-specific archives doesn't display recordings created with different connectUrl
Run the devserver and open the web client. Start and archive a recording using the regular cryostat connectUrl. Add a custom target with "localhost:9091" as the connect url. When you view the recordings for the "localhost:9091" target, the active recordings appear correctly, but the archived recordings table is empty.
@andrewazores Should the goal of this task be then to eliminate the possibility that two connectUrls are connecting to the same target? Or should we somehow link link ArchivedRecordings with targets the same way with ActiveRecordings? Seems that at least 4 targets can have the same localhost:9091 target, but have different connectUrls.
All 4 of these contain the same active recordings when they were discovered, but each have different archived recordings.
There is functionality somewhere to disallow new targets with the "same" connectUrls, but unfortunately it does not catch these cases.
The reason that happens is because our detection for the "same" URL is simply comparing the String representation of the URLs for equality, essentially. But that doesn't catch cases like what you have illustrated, where the Strings are different but the URL logically represents the same resource (target JVM). This can happen because we allow the "short form" host:1234 format as well as the full service:jmx:rmi:///... , so this is one easy way to have two logically-same URLs. You could also have multiple hostnames resolving to the same system, like in your case fedora and localhost. And, you could also have different JMX connectors too, so you can use URLs like service:jmx:remote+http://localhost:9091.
All that said, it is not the goal to "eliminate the possibility" of all of these URLs being valid and connecting to the same target. The possibility cannot be eliminated, it is in the nature of URLs. What we do want to do is to be able to recognize whether two URLs actually point at the exact same JVM instance. This means that when we connect to a JVM we should collect some information about it and use that to generate a computed ID for that JVM, and use that computed ID to identify subresources associated with the JVM (currently that means archived recordings and stored labels, basically). If we connect to the same JVM later on using a different URL then we still collect information about the JVM and compute the same ID, so we can retrieve the same subresources.
Janelle has been working on that here: https://github.com/cryostatio/cryostat/pull/971
Or should we somehow link link ArchivedRecordings with targets the same way with ActiveRecordings? All 4 of these contain the same active recordings when they were discovered, but each have different archived recordings.
This happens because the URL used when connecting to the target is also the "ID" we use for creating a subdirectory to store the archived recordings in within Cryostat's attached storage volume, so when you query for archived recordings you see them separated out by the URL that was used at the time. When you query for active recordings Cryostat actually goes and connects to the target JVM by that URL and pulls live information about what recordings are present in that target, and then wraps that back up into the Cryostat API response. Cryostat doesn't actually "know" (yet) that all four of the URLs are pointing at the same target to correlate that and give you back the same result, it's just a consequence of that information being pulled directly out of the target JVM vs being stored separately in our storage.
