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.