You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, Targets are defined expecting unique Connection URLs. However, it can be the case that there are multiple known Connection URLs that point to the same JVM instance - either because there are overlapping built-in discovery plugins or because the target is discoverable by one of those mechanisms and also has the Cryostat Agent attached. The JVM ID hash is therefore intended to help identify which Target instances are actually duplicate references.
A better data model would be that Targets can be defined, which have 0 or 1 JVM IDs (ie. null String for Target definitions that have not yet been connected to, or non-null String afterward - this ID should still be simply a column on the Target table). There would be a separate model for Connection URLs. A Connection URL would belong to exactly one Target, but a Target would have a list of zero or more Connection URLs. When a new Connection URL is to be added, the Cryostat server should attempt to open a connection there and compute (JMX)/retrieve (HTTP) the JVM ID. If the JVM ID cannot be determined then this Connection URL is rejected. If the JVM ID is determined then it should be linked to an existing Target record, if any, or a new corresponding Target should be created. This way, a Target record has a one-to-one relationship with an actual JVM instance.
Any background tasks, such as Automated Rule processing, that operate over Targets, can then choose any of the known Connection URLs for that Target to perform their work. Probably HTTP URLs should be preferred over JMX URLs, and some other ranking preference heuristics could be applied as well, for example localhost should be high priority, raw IP addresses should be next priority, hostnames (or hostname.local) should be next, and finally other URLs using full resolvable domains.
Currently, Targets are defined expecting unique Connection URLs. However, it can be the case that there are multiple known Connection URLs that point to the same JVM instance - either because there are overlapping built-in discovery plugins or because the target is discoverable by one of those mechanisms and also has the Cryostat Agent attached. The JVM ID hash is therefore intended to help identify which Target instances are actually duplicate references.
A better data model would be that Targets can be defined, which have 0 or 1 JVM IDs (ie. null String for Target definitions that have not yet been connected to, or non-null String afterward - this ID should still be simply a column on the Target table). There would be a separate model for Connection URLs. A Connection URL would belong to exactly one Target, but a Target would have a list of zero or more Connection URLs. When a new Connection URL is to be added, the Cryostat server should attempt to open a connection there and compute (JMX)/retrieve (HTTP) the JVM ID. If the JVM ID cannot be determined then this Connection URL is rejected. If the JVM ID is determined then it should be linked to an existing Target record, if any, or a new corresponding Target should be created. This way, a Target record has a one-to-one relationship with an actual JVM instance.
Any background tasks, such as Automated Rule processing, that operate over Targets, can then choose any of the known Connection URLs for that Target to perform their work. Probably HTTP URLs should be preferred over JMX URLs, and some other ranking preference heuristics could be applied as well, for example
localhost
should be high priority, raw IP addresses should be next priority, hostnames (orhostname.local
) should be next, and finally other URLs using full resolvable domains.See also #41
The text was updated successfully, but these errors were encountered: