Core library providing a convenience wrapper and headless stubs for managing JFR with JDK Mission Control API
Home Page: https://cryostat.io/
License: Other
Core library providing a convenience wrapper and headless stubs for managing JFR with JDK Mission Control API
Build:
./mvnw install to compile this core library and publish the artifacts to the
local Maven repository for consumption by other projects.
Consumers of this artifact may also pull it anonymously from Maven Central.
![dependabot-preview[bot] avatar](https://avatars.githubusercontent.com/in/2141?v=4 "dependabot-preview[bot]")
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Currently, when a PR is opened, only -core's own unit tests are run.
It would be great if, after that passes, the built -core artifact is then used to build a Cryostat container image, and that container image run through the Cryostat integration tests. This way any changes to -core are automatically tested for regressions in the primary consumer of the -core library.
-agent and -reports also consume -core, so they could also be tested against, but the Cryostat server is the most important one to test.
Spotbugs 4.8.0 introduced a new detector for CT_CONSTRUCTOR_THROW [0], which flags constructors that throw exceptions and may be left in a partially initialized and accessible state, see: OBJ11-J [1].
See: https://github.com/cryostatio/cryostat-core/actions/runs/6786037630/job/18445631568#step:4:1634
[INFO] --- spotbugs-maven-plugin:4.8.1.0:check (spotbugs) @ cryostat-core ---
[INFO] BugInstance size is 7
[INFO] Error size is 0
[INFO] Total bugs: 7
[ERROR] Medium: Exception thrown in class io.cryostat.core.EventOptionsBuilder at new io.cryostat.core.EventOptionsBuilder(ClientWriter, JFRConnection, Supplier) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.cryostat.core.EventOptionsBuilder, io.cryostat.core.EventOptionsBuilder] At EventOptionsBuilder.java:[line 50]At EventOptionsBuilder.java:[line 50] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Exception thrown in class io.cryostat.core.agent.AgentJMXHelper at new io.cryostat.core.agent.AgentJMXHelper(IConnectionHandle) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.cryostat.core.agent.AgentJMXHelper, io.cryostat.core.agent.AgentJMXHelper] At AgentJMXHelper.java:[line 45]At AgentJMXHelper.java:[line 45] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Exception thrown in class io.cryostat.core.agent.LocalProbeTemplateService at new io.cryostat.core.agent.LocalProbeTemplateService(FileSystem, Environment) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.cryostat.core.agent.LocalProbeTemplateService, io.cryostat.core.agent.LocalProbeTemplateService] At LocalProbeTemplateService.java:[line 45]At LocalProbeTemplateService.java:[line 45] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Exception thrown in class io.cryostat.core.net.JFRJMXConnection at new io.cryostat.core.net.JFRJMXConnection(ClientWriter, FileSystem, Environment, IConnectionDescriptor) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.cryostat.core.net.JFRJMXConnection, io.cryostat.core.net.JFRJMXConnection] At JFRJMXConnection.java:[line 96]At JFRJMXConnection.java:[line 96] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Exception thrown in class io.cryostat.core.net.JFRJMXConnection at new io.cryostat.core.net.JFRJMXConnection(ClientWriter, FileSystem, Environment, IConnectionDescriptor, List) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.cryostat.core.net.JFRJMXConnection, io.cryostat.core.net.JFRJMXConnection] At JFRJMXConnection.java:[line 91]At JFRJMXConnection.java:[line 91] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Exception thrown in class io.cryostat.core.net.JmxFlightRecorderService at new io.cryostat.core.net.JmxFlightRecorderService(JFRJMXConnection, ClientWriter) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.cryostat.core.net.JmxFlightRecorderService, io.cryostat.core.net.JmxFlightRecorderService] At JmxFlightRecorderService.java:[line 58]At JmxFlightRecorderService.java:[line 58] CT_CONSTRUCTOR_THROW
[ERROR] Medium: Exception thrown in class io.cryostat.core.serialization.SerializableRecordingDescriptor at new io.cryostat.core.serialization.SerializableRecordingDescriptor(IRecordingDescriptor) will leave the constructor. The object under construction remains partially initialized and may be vulnerable to Finalizer attacks. [io.cryostat.core.serialization.SerializableRecordingDescriptor, io.cryostat.core.serialization.SerializableRecordingDescriptor] At SerializableRecordingDescriptor.java:[line 88]At SerializableRecordingDescriptor.java:[line 88] CT_CONSTRUCTOR_THROW
[0] https://github.com/spotbugs/spotbugs/blob/4.8.0/CHANGELOG.md#added
[1] https://wiki.sei.cmu.edu/confluence/display/java/OBJ11-J.+Be+wary+of+letting+constructors+throw+exceptions
I'm getting the following error attempting to build with the latest JMC [1]:
$ ./gradlew build
Maven publication 'maven' contains dependencies that will produce a pom file that cannot be consumed by a Maven client.
- org.eclipse.core:runtime:3.10.0+ declared with a Maven incompatible version notation
- org.apache.commons:commons-lang3:3.8.1+ declared with a Maven incompatible version notation
> Task :compileJava FAILED
POM relocation to an other version number is not fully supported in Gradle : xml-apis:xml-apis:2.0.2 relocated to xml-apis:xml-apis:1.0.b2.
Please update your dependency to directly use the correct version 'xml-apis:xml-apis:1.0.b2'.
Resolution will only pick dependencies of the relocated element. Artifacts and other metadata will be ignored.
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
> Could not find org.apache.maven:maven-core:${project.prerequisites.maven}.
Required by:
project : > org.openjdk.jmc:org.openjdk.jmc.flightrecorder.configuration:7.1.0-SNAPSHOT > org.jacoco:jacoco-maven-plugin:0.8.3
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/5.2.1/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 2s
1 actionable task: 1 executed
It looks like Gradle doesn't handle this project.prerequisites.maven property (gradle/gradle#2218), but it seems odd to pull in Maven plugins for already built JMC artifacts. Perhaps this is something we need to fix in JMC.
The project currently uses classes/packages from jmc that aren't part of jmc-core, the api bundle for jmc. These should be requested in jmc upstream to be moved into jmc-core (if appropriate).
This is a decent time to make the request as JMC is now on 8.0.0-SNAPSHOT, which suggests api changes like this could be made.
In #275 we got some nice new PR CI features, but we lost the CI workflow that runs on push to main, ie. when a PR is merged. It should just a be a matter of running through the old pre-275 workflow again, basically mvn verify, so that we can have that extra assurance that main is really in a good buildable state.
When Cryostat attempts connection to a native image executable a NPE is thrown. It is thrown because some RuntimeMXBean attributes are not applicable on SubstrateVM (ClassPath, LibraryPath, etc), but cryostat assumes they are non-null. This is where the NPE happens.
See error trace:
May 10, 2023 4:10:40 PM io.cryostat.core.log.Logger info
INFO: Creating connection for service:jmx:rmi:///jndi/rmi://10-131-1-71.robert-quarkus-insights.pod:9091/jmxrmi
May 10, 2023 4:10:40 PM io.cryostat.core.log.Logger error
SEVERE: Exception thrown
java.lang.NullPointerException: Cannot invoke "Object.getClass()" because "attrObject" is null
at io.cryostat.core.net.JFRJMXConnection.getJvmId(JFRJMXConnection.java:223) ***[ already connected]
at io.cryostat.net.TargetConnectionManager.lambda$executeConnectedTaskAsync$2(TargetConnectionManager.java:153)
at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)
at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:483)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)
This was encountered on Scott's OpenShift cluster with the latest version of Cryostat. The native executable is a quarkus app.
I don't remember this occurring the last time I tested cryostat with native image. But that was a few months ago, and I also wasn't testing with openshift. I'll see if I can reproduce the same problem locally and update this issue afterward.
https://github.com/cryostatio/cryostat-core/blob/main/.github/workflows/maven-publish.yaml : https://github.com/cryostatio/cryostat-core/actions/workflows/maven-publish.yaml
https://github.com/cryostatio/cryostat-core/blob/main/.github/workflows/release.yaml : https://github.com/cryostatio/cryostat-core/actions/workflows/release.yaml
At some point I created maven-publish.yaml, which is the currently active workflow that triggers on release and which seems to be working well. I guess that this was meant to replace the older release.yaml, which maybe wasn't working as intended and so I had manually disabled it, but the release.yaml file is still there and has never been run. It may as well be removed.
The JDP-based JVM discovery client mirrors the three event types used by JMC: LOST/FOUND/CHANGED. LOST and FOUND are self-explanatory, but it is less obvious what exactly constitutes a CHANGED event.
When the JMC PacketProcessor processes a JDP packet, the information about that discovered JVM is cached using the packet's session ID. When another discovery packet with the same session ID is processed, the CHANGED event is emitted if any of the other discovery properties within the packet have changed, by comparing the new packet against the cached version.
Here is an example of the contents of such a JDP packet:
{MAIN_CLASS=com.redhat.rhjmc.containerjfr.ContainerJfr, JMX_SERVICE_URL=service:jmx:rmi:///jndi/rmi://container-jfr:9091/jmxrmi, DISCOVERABLE_SESSION_UUID=141d27e8-3f58-42a6-9dd5-cf8ca951cc9d, BROADCAST_INTERVAL=5000, PROCESS_ID=1}
None of these properties appear likely to ever actually change at runtime.
In ContainerJFR itself we now have a situation where these three event types are the expected types to be implemented for alternate target discovery schemes as well, ex. via an OpenShift watch. There, the semantics of LOST/FOUND are clear enough and easy to translate between OpenShift watch events and our target discovery events. However, the CHANGED event is murky at best. The corresponding OpenShift watch event is emitted in many more scenarios than where ContainerJFR would consider something to simply have been changed, and so it is translated into a LOST/FOUND pair, with the web-client making the assumption that at least the service URL is static for a single target. This approach might be the best bet to take for -core and ContainerJFR itself - remove the CHANGED event, and in any scenario where it would seem to make sense to use, instead emit a LOST/FOUND pair. Clients can then update themselves accordingly, and should end up with the same net state change.
I, uh, think that was a little excessive :sweat_smile:
I suspect this is the problem:
The concurrency group is based on the run ID, but each time the PR is relabelled or a new commit is pushed I think that triggers a new run with a new ID, so many concurrent jobs can be running in the background on the same actual code if we're just relabelling the PR etc.
Originally posted by @andrewazores in #279 (comment)
Using the following XML probe template definition, which I generated using the JMC wizard:
<jfragent>
<config>
<classprefix>__JFREvent</classprefix>
<allowtostring>false</allowtostring>
<allowconverter>false</allowconverter>
</config>
<events>
<event id="io.cryostat.quarkus.demo.event1">
<label>Cryostat Quarkus Demo Event 1</label>
<class>jakarta.persistence.EntityManager</class>
<stacktrace>true</stacktrace>
<rethrow>true</rethrow>
<location>WRAP</location>
<method>
<name>find</name>
<descriptor>(Ljava/lang/Class;Ljava/lang/Object;)Ljava/lang/Object;</descriptor>
<parameters>
<parameter index="0">
<name>klazz</name>
<contenttype>Class</contenttype>
</parameter>
<parameter index="1">
<name>key</name>
<contenttype>None</contenttype>
</parameter>
</parameters>
</method>
</event>
</events>
</jfragent>I get the following stack trace when attempting to upload it to Cryostat on the Events view:
Jun 20, 2023 8:28:49 PM io.cryostat.core.log.Logger error
SEVERE: cvc-enumeration-valid: Value 'CLASS' is not facet-valid with respect to enumeration '[None, Bytes, Timestamp, Millis, Nanos, Ticks, Address, OSThread, JavaThread, StackTrace, Class, Percentage]'. It must be a value from the enumeration.
Jun 20, 2023 8:28:49 PM io.cryostat.core.log.Logger warn
WARNING: HTTP 400: cvc-enumeration-valid: Value 'CLASS' is not facet-valid with respect to enumeration '[None, Bytes, Timestamp, Millis, Nanos, Ticks, Address, OSThread, JavaThread, StackTrace, Class, Percentage]'. It must be a value from the enumeration.
io.vertx.ext.web.handler.HttpException: Bad Request
Caused by: io.cryostat.net.web.http.api.v2.ApiException: cvc-enumeration-valid: Value 'CLASS' is not facet-valid with respect to enumeration '[None, Bytes, Timestamp, Millis, Nanos, Ticks, Address, OSThread, JavaThread, StackTrace, Class, Percentage]'. It must be a value from the enumeration.
at io.cryostat.net.web.http.api.v2.ProbeTemplateUploadHandler.handle(ProbeTemplateUploadHandler.java:158)
at io.cryostat.net.web.http.api.v2.AbstractV2RequestHandler.handle(AbstractV2RequestHandler.java:108)
at io.cryostat.net.web.http.api.v2.AbstractV2RequestHandler.handle(AbstractV2RequestHandler.java:71)
at io.vertx.ext.web.impl.BlockingHandlerDecorator.lambda$handle$0(BlockingHandlerDecorator.java:48)
at io.vertx.core.impl.ContextBase.lambda$null$0(ContextBase.java:137)
at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:264)
at io.vertx.core.impl.ContextBase.lambda$executeBlocking$1(ContextBase.java:135)
at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: io.cryostat.core.agent.ProbeValidationException: cvc-enumeration-valid: Value 'CLASS' is not facet-valid with respect to enumeration '[None, Bytes, Timestamp, Millis, Nanos, Ticks, Address, OSThread, JavaThread, StackTrace, Class, Percentage]'. It must be a value from the enumeration.
at io.cryostat.core.agent.ProbeValidator$ProbeValidatorErrorHandler.error(ProbeValidator.java:121)
at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:138)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:396)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:327)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:284)
at java.xml/com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator$XSIErrorReporter.reportError(XMLSchemaValidator.java:512)
at java.xml/com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.reportSchemaError(XMLSchemaValidator.java:3600)
at java.xml/com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.elementLocallyValidType(XMLSchemaValidator.java:3437)
at java.xml/com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.processElementContent(XMLSchemaValidator.java:3347)
at java.xml/com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleEndElement(XMLSchemaValidator.java:2373)
at java.xml/com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.endElement(XMLSchemaValidator.java:944)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1728)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2899)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:605)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:112)
at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:542)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:889)
at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:825)
at java.xml/com.sun.org.apache.xerces.internal.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:178)
at java.xml/com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:115)
at io.cryostat.core.agent.ProbeValidator.validate(ProbeValidator.java:89)
at java.xml/javax.xml.validation.Validator.validate(Validator.java:124)
at io.cryostat.core.agent.ProbeTemplate.deserialize(ProbeTemplate.java:98)
at io.cryostat.core.agent.LocalProbeTemplateService.getTemplate(LocalProbeTemplateService.java:114)
at io.cryostat.net.web.http.api.v2.ProbeTemplateUploadHandler.handle(ProbeTemplateUploadHandler.java:137)
... 11 more
Caused by: org.xml.sax.SAXParseException; lineNumber: 20; columnNumber: 57; cvc-enumeration-valid: Value 'CLASS' is not facet-valid with respect to enumeration '[None, Bytes, Timestamp, Millis, Nanos, Ticks, Address, OSThread, JavaThread, StackTrace, Class, Percentage]'. It must be a value from the enumeration.
at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:204)
at java.xml/com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:135)
... 34 more
Jun 20, 2023 8:28:49 PM org.slf4j.impl.JDK14LoggerAdapter fillCallerData
WARNING: 10.89.1.31 - - [Tue, 20 Jun 2023 20:28:49 GMT] 16ms "POST /api/v2/probes/jmc-agent-probe.xml HTTP/1.1" 400 310 bytes "http://localhost:8181/events?agentTab=agent-template" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/113.0"
Jun 20, 2023 8:28:50 PM org.slf4j.impl.JDK14LoggerAdapter fillCallerData
INFO: 0:0:0:0:0:0:0:1%0 - - [Tue, 20 Jun 2023 20:28:50 GMT] 0ms "GET /health/liveness HTTP/1.1" 204 0 bytes "-" "curl/7.61.1"
Removing the <parameters> element fixes the immediate problem and I can continue, but without being able to capture method parameters in the event.
Jun 20, 2023 8:32:28 PM io.cryostat.core.log.Logger error
SEVERE: new_file.xml
Jun 20, 2023 8:32:28 PM io.cryostat.core.log.Logger error
SEVERE: HTTP 500: new_file.xml
io.vertx.ext.web.handler.HttpException: Internal Server Error
Caused by: io.cryostat.net.web.http.api.v2.ApiException: new_file.xml
at io.cryostat.net.web.http.api.v2.ProbeTemplateUploadHandler.handle(ProbeTemplateUploadHandler.java:161)
at io.cryostat.net.web.http.api.v2.AbstractV2RequestHandler.handle(AbstractV2RequestHandler.java:108)
at io.cryostat.net.web.http.api.v2.AbstractV2RequestHandler.handle(AbstractV2RequestHandler.java:71)
at io.vertx.ext.web.impl.BlockingHandlerDecorator.lambda$handle$0(BlockingHandlerDecorator.java:48)
at io.vertx.core.impl.ContextBase.lambda$null$0(ContextBase.java:137)
at io.vertx.core.impl.ContextInternal.dispatch(ContextInternal.java:264)
at io.vertx.core.impl.ContextBase.lambda$executeBlocking$1(ContextBase.java:135)
at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.nio.file.FileAlreadyExistsException: new_file.xml
at io.cryostat.core.agent.LocalProbeTemplateService.addTemplate(LocalProbeTemplateService.java:98)
at io.cryostat.net.web.http.api.v2.ProbeTemplateUploadHandler.handle(ProbeTemplateUploadHandler.java:136)
... 11 more
Jun 20, 2023 8:32:28 PM org.slf4j.impl.JDK14LoggerAdapter fillCallerData
SEVERE: 10.89.1.31 - - [Tue, 20 Jun 2023 20:32:28 GMT] 11ms "POST /api/v2/probes/jmc-agent-probe.xml HTTP/1.1" 500 96 bytes "http://localhost:8181/events?agentTab=agent-template" "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/113.0"
See #238 . After failing to upload a template once, a retry with the file corrected fails with the above. Once in this state it doesn't appear to be recoverable - all upload attempts will fail this way.
Nice, it passed - would be even nicer if the status got reported, either as a comment again like we already have elsewhere, or [as a status check item](https://josh-ops.com/posts/using-github-checks-api/)
Originally posted by @andrewazores in #279 (comment)
In #201 , parts of the embedded JMC sources were upgraded from 7.1.1 to 8.2.0. It appears that not all of the sources saw the upgrade: automated analysis rules were upgraded, but at least the FlightRecorderServiceV2 (a JMX-related class) was not. This is the cause of #154 / #155 , which were erroneously closed by #201. The remaining embedded sources such as the FlightRecorderServiceV2 should all be upgraded to correspond to JMC 8.2.0.
See also #173
The jdp bundle was moved from JMC application to core back in 2020 [0], and was a part of the 8.0.0 release.
Since cryostat-core was updated to use JMC 8.2.0 sources as of #201, perhaps it'd be nice to also bring in jdp from maven central alongside it's other core counterparts (common/flightrecorder/etc.).
Currently we're embedding classes from the flightrecorder, rjmx, jdp, and ui/common. There's an ongoing effort to refactor flightrecorder.configuration and ui.common into jmc-core. Once this upstream refactoring is done and the changes are available on maven central we should update cryostat accordingly.
Depends on the following upstream issues:
https://bugs.openjdk.org/browse/JMC-7308
https://bugs.openjdk.org/browse/JMC-7307
Builds should be published somewhere public like Maven Central so that dependent projects (ex. Cryostat itself) can easily consume this -core library without having to first manually retrieve and build it.
JMC 8 (8.0.1 now) is released and available on Maven Central:
This workflow has been useful in other repos, so it should be enabled here too:
https://github.com/cryostatio/cryostat/blob/main/.github/workflows/dependent-issues.yml
Logger is now an abstraction around SLF4J, which is itself a logging abstraction/facade. This is redundant and no longer useful, so our Logger definition should be removed and simply replaced with the SLF4J equivalent.
https://stackoverflow.com/questions/645208/java-rmi-nosuchobjectexception-no-such-object-in-table
May 09, 2023 9:55:24 PM io.cryostat.core.log.Logger info
INFO: Connection for service:jmx:rmi:///jndi/rmi://10-131-1-37.redacted.pod:9091/jmxrmi closed
May 09, 2023 9:55:24 PM io.cryostat.core.log.Logger error
SEVERE: Exception thrown
org.openjdk.jmc.rjmx.ConnectionException caused by java.rmi.NoSuchObjectException: no such object in table
at org.openjdk.jmc.rjmx.internal.RJMXConnection.connect(RJMXConnection.java:345)
at io.cryostat.core.net.JFRJMXConnection.attemptConnect(JFRJMXConnection.java:443)
at io.cryostat.core.net.JFRJMXConnection.connect(JFRJMXConnection.java:399)
at io.cryostat.core.net.JFRJMXConnection.getJvmId(JFRJMXConnection.java:204)
at io.cryostat.net.TargetConnectionManager.lambda$executeConnectedTaskAsync$2(TargetConnectionManager.java:153)
at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646)
at java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:483)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)
Caused by: java.rmi.NoSuchObjectException: no such object in table
at java.rmi/sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:304)
at java.rmi/sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:280)
at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:165)
at java.management.rmi/javax.management.remote.rmi.RMIServerImpl_Stub.newClient(RMIServerImpl_Stub.java:83)
at java.management.rmi/javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2107)
at java.management.rmi/javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:321)
at org.openjdk.jmc.rjmx.internal.RJMXConnection.connectJmxConnector(RJMXConnection.java:575)
at org.openjdk.jmc.rjmx.internal.RJMXConnection.establishConnection(RJMXConnection.java:552)
This and any other associated classes should be renamed to more accurately reflect that these classes relate to the JMC BI Agent, not the Cryostat Agent. The package name should probably be changed as well.
The InterruptibleReportGenerator only implements processing of a JFR file input to a prettified HTML report document containing the automated analysis results. This is useful for display to human consumers, but less helpful for building further automation workflows around the results since the HTML would need to be parsed and the scores extracted back out of the document, wasting processing resources on both ends. We should implement another method that performs the same rules analyses but returns the rules results/scores as some simpler, plainer data structures than the formatted HTML document, ex. a simple Java Map where the keys are the rule name and the values are a structure containing the rule's 0-100 points score and the descriptive text that would be contained in the expanded HTML doc section for the rule. This can then be easily serialized into ex. JSON by cryostat or cryostat-reports and exposed as a machine-processable API endpoint.
This should be fixed automatically when #95 is fixed.
It looks like JMC is handling this with good old Java
MessageFormat,ResourceBundle, etc. From what I can tell it just lets theResourceBundleuse the default locale that the JVM picked on startup, which it would have determined from environment variables etc. We will probably need to do some hacking, or offer some patches to JMC for their Rules package, so that it's possible to get these rules report results with an override for the locale, in case the JVM is serving results to remote users like in our case. Otherwise if we need to hack it, then I'm not sure the threadsafety of setting the JVM's global locale, but maybe we can explore options around there.
Originally posted by @andrewazores in cryostatio/cryostat-web#968 (comment)
ex.
https://github.com/cryostatio/cryostat-core/actions/runs/7020606268 , from https://github.com/cryostatio/cryostat-core/actions/runs/7020606268/workflow . This one succeeded.
and
https://github.com/cryostatio/cryostat-core/actions/runs/7020606288 , from https://github.com/cryostatio/cryostat-core/actions/runs/7020606288/workflow . This one failed:
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ cryostat-core ---
[INFO] Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
[INFO] Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar (251 kB at 16 MB/s)
[INFO] Uploading to github: https://maven.pkg.github.com/cryostatio/cryostat-core/io/cryostat/cryostat-core/2.24.0/cryostat-core-2.24.0.jar
[INFO] Uploading to github: https://maven.pkg.github.com/cryostatio/cryostat-core/io/cryostat/cryostat-core/2.24.0/cryostat-core-2.24.0.pom
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 40.170 s
[INFO] Finished at: 2023-11-28T15:00:51Z
[INFO] ------------------------------------------------------------------------
Error: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project cryostat-core: Failed to deploy artifacts: Could not transfer artifact io.cryostat:cryostat-core:jar:2.24.0 from/to github (https://maven.pkg.github.com/cryostatio/cryostat-core): authorization failed for https://maven.pkg.github.com/cryostatio/cryostat-core/io/cryostat/cryostat-core/2.24.0/cryostat-core-2.24.0.jar, status: 403 Forbidden -> [Help 1]
it seems to me that release.yaml can just be removed, but maven-publish.yaml could perhaps use the permissions updates that are present there. maven-publish.yaml uses newer reusable workflows and also correctly builds the dependency using a JDK 11.
The method was created once in [cryostat-reports] as part of the /report path before I realized that it needed to also be used in cryostat itself part of -core. It also needs to be removed from cryostat, and refactored in cryostat SubprocessReportGenerator
Core implementation of cryostatio/cryostat#918
Subtask of cryostatio/cryostat#576
Goal: Implement the backend classes needed to interact with the agent in core. In particular we need class(es) for communicating with the agent over JMX. We have access to org.openjdk.jmc.rjmx in cryostat already so no additional dependencies should be needed and we should be able to reuse similar classes to the JMC Agent Plugin.
After #96 updated jsoup in response to a security vulnerability, we need to release a new version and have it consumed by Cryostat.
Log format should be configurable to rearrange fields, and include extra fields not currently supported (ex. timestamp). This may mean removing the actual logger implementation and wrapping the abstraction around another lightweight logging library, if need be.
That would make sense, though the constructors for that exception are not visible here. I'll file a separate bug to fix that in `-core` and update these lines.
Originally posted by @andrewazores in cryostatio/cryostat-agent#165 (comment)
The agent frequently prints log warnings like this:
2023-05-10 21:29:56,251 INFO [io.cry.age.WebServer] (cryostat-agent-worker-1) Using 'deflate' encoding
2023-05-10 21:29:56,251 WARNING [io.cry.age.rem.MBeanContext] (cryostat-agent-worker-1) Call failed: java.lang.UnsupportedOperationException: Boot class path mechanism is not supported
This does not actually break anything, the exception is just caught and logged as a warning. This happens when the agent is trying to gather information about the host JVM from MBeans and reads the attribute in question, which is unsupported by the host JVM.
I think the "boot class path mechanism" is not actually supported by any JDK past 9, but the agent is targeted to and built for JDK11+. In practice this means that this harmless warning is useless and will always be emitted. The agent should either be targeted to older JDK versions (back to 8 perhaps), or it should simply not check for this MBean attribute if it will only ever be attached to JVMs where it is not supported.
Targeting JDK 8 comes with the technical difficulty that the Agent is currently implemented using the built-in JDK webserver, which is an 11 feature, so targeting an older version would require adding a dependency to replace this webserver. However, it does expand the potential userbase of the agent, since 8 is still a commonly used release, and later updates of 8 do have JFR.
Bumps jsoup to 1.15.3 to fix CVE-2022-36033.
Currently using spotbugs version 4.2.3, but 4.7.0 is out. This version should be bumped and any new bugs found fixed accordingly.
We've never used this and now that we have JSON reports format, which is the expected way forward, we will never use report transformers. They should be removed along with the JSoup dependency. Event templates services that use JSoup can use jdk.jfr.Configuration instead.
// TODO it would be very nice to record a JFR event here to pick up in
// Cryostat's own profiling template, to compare the different rule
// implementations and the time they each take to process with various
// source recording settings
Related to cryostatio/cryostat#461
I can work on this.
Originally posted by @jan-law in cryostatio/cryostat#461 (comment)
https://github.com/cryostatio/cryostat/blob/main/.github/dependabot.yml
https://github.com/cryostatio/cryostat/blob/main/.github/CODEOWNERS
The above files should be referenced for creating a similar configuration for this project.
To avoid dealing with too large a number of Dependabot PRs, any common dependency between this project and the main Cryostat project can have its version manually updated in the pom.xml to match Cryostat's: https://github.com/cryostatio/cryostat/blob/main/pom.xml . These have recently been updated already.
JMC has a useful utility class ConnectionToolkit with many static methods that would also be useful in ContainerJFR, ex. createServiceURL, getDefaultPort, getHostName, and perhaps the various getXBeans. A simple wrapper abstraction around this class should be created and added to -core so that it can be exposed to ContainerJFR while allowing -core to possibly reimplement the features independently of JMC in the future.
Update the RuleEvaluation to support the updated rule IResult fields: https://docs.oracle.com/en/java/java-components/jdk-mission-control/8/jmc-flightrecorder-rules/org/openjdk/jmc/flightrecorder/rules/IResult.html
-core's RuleEvaluation object should probably be updated with Explanation, Severity, Solution, and Summary in multiple fields instead of 1 big description field in JMC 7. suggestRecordingSettings could also be looked into.
JSoup is used for some light processing of .jfc XML documents. Unfortunately, we also expose the JSoup Document class as part of our own public API.
Document type should be abstracted away so that any library used for processing XML is an internal implementation detail of this libraryJDK9+ module-info should be included, so that core internal classes do not need to rely on package namespacing alone (which is already not working too well) to delineate public API from internal implementations.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.