-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(serialization): recording serialization properly converts recording state types #314
fix(serialization): recording serialization properly converts recording state types #314
Conversation
CI failure looks like the builder is trying to use I think the CI builder needs to build |
cryostat-core/src/main/java/org/openjdk/jmc/rjmx/services/jfr/internal/RecordingDescriptorV2.java Lines 91 to 104 in e77984d
jdk.jfr.recording or the RecordingStates sets?
|
This is what I intended when I first implemented the Cryostat build testing, but I think there's an error caching or retrieving the cached files. I'll take a look at it right now. |
Basically I painted us into a corner a long time ago. We probably want to move in the direction of just using the One nice thing about the JMC stuff is that it provides nicer type signatures in many cases that make it clearer/less error-prone what you're doing - though sometimes this is a little boilerplate-y. On the downside, those classes and the various Unit types don't always serialize well, and there is at least this one case where the state of a recording is modelled differently between the two packages. I don't know if that recording state difference is because the JMC side of it is more geared toward JMC's UI display, or if perhaps it's an older state model that looks more like the old V1 proprietary JFR implementation rather than the V2 OpenJDK JFR implementation. Regardless of the reason for the difference, we would probably be better off migrating away from using JMC's abstractions except in cases where we really want/need it, like for Automated Analysis. But that will be a pretty big undertaking to refactor all of that and test for any regressions (in serialization especially), and it's just as cleanup/tech-debt chore rather than feature work, so it hasn't been very high priority. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
cryostat-core/src/main/java/org/openjdk/jmc/rjmx/services/jfr/internal/RecordingDescriptorV1.java Line 101 in e77984d
cryostat-core/src/main/java/org/openjdk/jmc/rjmx/services/jfr/internal/RecordingDescriptorV2.java Line 91 in e77984d
Looks to me like the JMC RecordingState model is indeed modelled after the old V1 JFR implementation, and they just mapped the OpenJDK JFR V2 states onto the existing model, which we've inherited from JMC. |
In this case it would also be nice if Edit: I've opened: https://bugs.openjdk.org/browse/JMC-8153 |
66e7df8
to
d424c7e
Compare
d424c7e
to
06b246d
Compare
To run smoketest:
|
/build_test |
Cryostat Test: All tests pass ✅ |
Did you see this @andrewazores
|
No, I didn't notice that. Where is it from? |
Here.. |
Ah, I see. Odd that the workflow step succeeded despite those errors. Despite the errors it looks like it still did run the tests successfully, too... |
Yes, was wondering the same how did we get to receive the |
Fixes #313