Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 5. Known issues
Sometimes a Cryostat release might contain an issue or issues that Red Hat acknowledges and might fix at a later stage during the product’s development. Review each known issue for its description and its resolution.
Cryostat Operator upgrade
- Description
When updating your Cryostat Operator subscription from Cryostat 2.0 to Cryostat 2.1, you must change the update channel from
stable-2.0tostable.After this upgrade process, some Red Hat OpenShift objects that were created by the OpenShift Operator from Cryostat 2.0 will contain some outdated definitions. These definitions can result in connection issues among Cryostat components when you interact with your Cryostat 2.1 instance.
- Workaround
Remove Cryostat 2.0 services and deployments that exist in your Cryostat 2.1 instance.
Example that shows removal of Cryostat 2.0 services and deployments from a Cryostat 2.1 instance
oc project <cryostat_project> cryostats=$(oc get cryostat --template \ '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}') for cryostat in ${cryostats}; do oc delete svc,deploy -lapp="${cryostat}" doneAfter you remove these definitions, your Cryostat Operator creates services and deployments by using the Cryostat 2.1 object definitions. This restores connectivity among Cryostat components, and preserves JFR recordings that were created by Cryostat 2.0 in Cryostat 2.1.
Additional resources
Deleted entries in the Archived Recordings table
- Description
- The Archived Recordings table on the Recordings menu item does not immediately remove any archived recordings that you have deleted.
- Workaround
- Select any menu item, except Recordings, and then select the Recordings menu item. The Archived Recordings table now displays all the available archived recordings.
Cryostat's API handling behavior
- Description
Cryostat 2.1 does not concurrently handle API requests, which can lead to performance issues for your Cryostat instance.
In the following diagrams, the following symbols indicate actions:
- A parallel line (|): Cryostat is processing an API request.
- A dotted line (.): Cryostat has not yet processed a request.
An "x": Cryostat has processed a request.
Figure 5.1. Example of the current behavior of how Cryostat handles API requests
API request A, a slow request, is running while a client issues API request B and then API request C, fast requests. Cryostat cannot process API request B until it has finished processing API request A. This activity is similar for how Cryostat handles API requests B and C.
Figure 5.2. Example of the expected behavior of how Cryostat handles API requests
The client sent each request at different time intervals. Cryostat processes API requests B and C before API request A, because Cryostat can process fast requests before any slow requests. This behavior reduces any performance issues with Cryostat, because Cryostat can concurrently handle API requests and send responses back to the client.
- Workaround
- Currently no workaround exists for this issue.
Duplicate file name displays under the Archived Recordings table
- Description
An issue occurs under the Archived Recordings table on the Recordings menu item, when you re-upload a file with an identical file name to a file that already exists on the table.
If you attempt to delete or edit your re-uploaded file with this known issue, Cryostat applies the changes to both files. These changes can impact how you interact with the files, because you might be using Cryostat to analyze the incorrect file.
NoteThis issue does not occur under the following scenarios:
- If you immediately archive two active recordings that relate to the same target JVM.
- If you re-upload an identical file more than once to Cryostat. Cryostat stores each re-uploaded file in a storage location that does not relate to a specific target JVM.
For both these scenarios, Cryostat appends a number to the second file to distinguish it from the first file.
The following directory structure example shows the
20220401T212052Z.jfrarchive recording file in a storage location that corresponds to the selected target JVM,archive. When you re-upload an identically named file from your local system to Cryostat’s archives location, Cryostat stores the file in a storage location that does not correspond to any target JVM,unlabelled.archive/ ├── file-uploads ├── ONSXE5TJMNSTU2TNPA5HE3LJHIXS6L3KNZSGSL3SNVUTULZPMNZHS33TORQXIORZGA4TGL3KNV4HE3LJ │ └── es-andrewazor-demo-Main_foo_20220401T212052Z.jfr └── unlabelled └── es-andrewazor-demo-Main_50mb_20211224T172734Z.2.jfr └── es-andrewazor-demo-Main_50mb_20211224T172734Z.jfr └── es-andrewazor-demo-Main_foo_20220401T212052Z.jfrBased on the previous example, the current behavior of the re-upload operation on the Archived Recordings table shows two files with the same name. Cryostat applies the same name to both files, because Cryostat identifies each file as having different storage locations.
The expected behavior of the re-upload operation on Cryostat would append a subsequent number to the re-uploaded file. This means that this file does not share the same name as the file that exists before it in the table.
- Workaround
- Currently no workaround exists for this issue.
