Chapter 4. Fixed issues

The Cryostat release might include fixes for issues that were identified in earlier releases of Cryostat. Review each fixed issue note for a description of the issue and the subsequent fix.

The following issues have been fixed in the Cryostat 2.4 release:

Rule activation failures on late-connecting targets

Before Cryostat 2.4, Cryostat might fail to trigger automated rules on discovered JVM targets. This issue could occur when the discovery mechanism (for example, OpenShift endpoints querying) informed Cryostat about a new target container before the JVM in the container was ready to accept incoming JMX requests.

Cryostat 2.4 resolves this issue by performing rechecks for a target JVM that was previously non-connectible and reattempting rule triggering at regular frequent intervals for a set period. This fix helps to resolve any connection issues between Cryostat and JVMs in a faster timeframe. This fix also helps to avoid inconsistent or unpredictable rule-triggering behavior when toggling between the enabling or disabling of rules.

Discovery plug-in registration failures

Before Cryostat 2.4, instances of the Cryostat agent might fail to register with the Cryostat server. Even though the registration protocol has defined behaviors to help identify such failures and reset the registration, these defined behaviors might also fail in other situations. If both of these failures occurred, the Cryostat server would have an invalid agent registration record that the server considered to be valid. In this situation, the agent might make further attempts to register based on the assumption that the previous registration failed. However, the server would subsequently reject the agent’s attempts to register again based on the assumption that the agent was already registered. This left the agent and server unable to recognise each other or to reset the registration status.

Cryostat 2.4 resolves this issue and provides more reliable agent discovery registration.

Server startup failures due to unavailable agent instances

Before Cryostat 2.4, if you shut down and restarted the Cryostat server, the server might fail to restart successfully. This issue occurred if you shut down a server that had valid agent registration records and then you shut down these agent instances without restarting the agents. In this situation, at server startup, the server could see the preexisting agent registration records and expected these agent instances to still exist. However, because the agents were no longer available, the server startup subsequently failed.

Cryostat 2.4 resolves this issue. In this release, at server startup, if agent registration records still exist for agent instances that are no longer available, the server deletes these registration records and the server startup continues as normal.

Unwanted override of container-tuning properties by cryostat-reports and jfr-datasource

The cryostat-reports and jfr-datasource containers both use the OpenJDK UBI runtime image. Before Cryostat 2.4, these containers were mistakenly configured to override the various container-tuning properties that the base image’s entry-point script performed.

In Cryostat 2.4, the cryostat-reports and jfr-datasource containers no longer override the container-tuning properties, and these parameters are now active.

Truncation of JFR data when restarting flight recordings by using automated rules

Before Cryostat 2.4, when a client sent a request to create a JFR recording by using automated rules, this might lead to unexpected truncation of JFR data for existing recordings. This could occur if the client request included a restart=true setting but an existing recording with the same name was not already in a STOPPED state. In this situation, the server automatically stopped, deleted, and recreated the recording, which resulted in a loss of non-archived recording data.

Cryostat 2.4 resolves this issue by introducing a replace parameter, which supersedes the restart parameter that was available in previous releases. When you define an automated rule to create a JFR recording, you can now include a replace=stopped setting in the client request. This setting instructs the server to restart a JFR recording only if the existing recording is in a STOPPED state. If the existing recording is in another state such as RUNNING, the server rejects the request.

Container startup failure due to small CPU limits

Before Cryostat 2.4, if Cryostat was deployed with small CPU limits, the container might fail to start.

Cryostat 2.4 resolves this issue by ensuring that the container can start even if Cryostat is deployed with small CPU limits.