From hirt at openjdk.java.net Mon Sep 6 13:00:52 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 6 Sep 2021 13:00:52 GMT Subject: RFR: 7378: Update platform to 2021-06 Message-ID: ...and removing old ones. ------------- Commit messages: - Fix - Various fixes - Updating Spotbugs and Tycho - Another unused import - Unused import - Unrelated - fixing writer classpath, since tests were moved out into separate bundle - Removing old platforms - 7378: Update platform to 2021-06 Changes: https://git.openjdk.java.net/jmc/pull/301/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=301&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7378 Stats: 365 lines in 34 files changed: 60 ins; 242 del; 63 mod Patch: https://git.openjdk.java.net/jmc/pull/301.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/301/head:pull/301 PR: https://git.openjdk.java.net/jmc/pull/301 From hirt at openjdk.java.net Mon Sep 6 13:00:52 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Mon, 6 Sep 2021 13:00:52 GMT Subject: RFR: 7378: Update platform to 2021-06 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 22:08:14 GMT, Marcus Hirt wrote: > ...and removing old ones. > We could revert this change with module export added in its respective pom.xml (commented above). I think it's fine. We don't support Java 1.4 anymore. :) @guruhb - do you happen to know if there is a way to suppress all the new Tycho warnings? (Maven Artifact blablabla is not a bundle and will be ignored, automatic wrapping of such artifacts can be enabled with wrapAsBundle in target platform configuration) ------------- PR: https://git.openjdk.java.net/jmc/pull/301 From jpbempel at openjdk.java.net Mon Sep 6 15:29:54 2021 From: jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Mon, 6 Sep 2021 15:29:54 GMT Subject: RFR: 7332: Show stacktraces for constant values from stacktrace pool Message-ID: Replace the default Object.ToString of JfrStackTraces by the top frame and linked to the StacktraceView for better visualization Example: Screenshot 2021-09-06 at 17 21 42 ------------- Commit messages: - 7332: Show stacktraces for constant values from stacktrace pool Changes: https://git.openjdk.java.net/jmc/pull/305/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=305&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7332 Stats: 24 lines in 2 files changed: 21 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jmc/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/305/head:pull/305 PR: https://git.openjdk.java.net/jmc/pull/305 From jpbempel at openjdk.java.net Mon Sep 6 15:55:56 2021 From: jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Mon, 6 Sep 2021 15:55:56 GMT Subject: RFR: 7332: Show stacktraces for constant values from stacktrace pool [v2] In-Reply-To: References: Message-ID: <7nVMIUkyy7ti7wkP4710ys0P6D12t-7oO7it38SAv_c=.9f6e56a1-b683-4936-877a-f579f8816c1a@github.com> > Replace the default Object.ToString of JfrStackTraces by the top frame > and linked to the StacktraceView for better visualization > > Example: > Screenshot 2021-09-06 at 17 21 42 Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: fix formatting ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/305/files - new: https://git.openjdk.java.net/jmc/pull/305/files/578ffcbb..bd59d11b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=305&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=305&range=00-01 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jmc/pull/305.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/305/head:pull/305 PR: https://git.openjdk.java.net/jmc/pull/305 From ghb at openjdk.java.net Mon Sep 6 16:47:38 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Mon, 6 Sep 2021 16:47:38 GMT Subject: RFR: 7378: Update platform to 2021-06 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 22:08:14 GMT, Marcus Hirt wrote: > ...and removing old ones. > (Maven Artifact blablabla is not a bundle and will be ignored, automatic wrapping of such artifacts can be enabled with wrapAsBundle in target platform configuration) This looks very interesting to solve and tycho is now capable of converting non OSGi Bundle to OSGi for maven dependency if we add ``` wrapAsBundle ``` . Note : [https://wiki.eclipse.org/Tycho/Target_Platform#.22POM_dependencies_consider.22](https://wiki.eclipse.org/Tycho/Target_Platform#.22POM_dependencies_consider.22) but there is a catch .. If we use non OSGi dependency the "Bundle Symbolic name generated by tycho 2.x will be "**groupid.artifactId**" where as the **p2-maven-plugin** (currently used for converting non OSGi to OSGi and hosting as a local p2 server convert Bundle Symbolic name to "**groupId**" (Note the missing artifactId There are two solution i could think off and None of them are good at this point of time Solution 1 : Unify Core with application and remove p2-maven-plugin (+ remove releng /third-party) Solution 2 : Append Symbolic name with artifactId generated by p2-maven-plugin to match with the expected tycho compiler plugin (Not tested , but this might work) . ------------- PR: https://git.openjdk.java.net/jmc/pull/301 From ghb at openjdk.java.net Mon Sep 6 16:56:37 2021 From: ghb at openjdk.java.net (Guru Hb) Date: Mon, 6 Sep 2021 16:56:37 GMT Subject: RFR: 7378: Update platform to 2021-06 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 22:08:14 GMT, Marcus Hirt wrote: > ...and removing old ones. looks good to me ------------- Marked as reviewed by ghb (Reviewer). PR: https://git.openjdk.java.net/jmc/pull/301 From hirt at openjdk.java.net Tue Sep 7 12:16:41 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 7 Sep 2021 12:16:41 GMT Subject: RFR: 7332: Show stacktraces for constant values from stacktrace pool [v2] In-Reply-To: <7nVMIUkyy7ti7wkP4710ys0P6D12t-7oO7it38SAv_c=.9f6e56a1-b683-4936-877a-f579f8816c1a@github.com> References: <7nVMIUkyy7ti7wkP4710ys0P6D12t-7oO7it38SAv_c=.9f6e56a1-b683-4936-877a-f579f8816c1a@github.com> Message-ID: On Mon, 6 Sep 2021 15:55:56 GMT, Jean-Philippe Bempel wrote: >> Replace the default Object.ToString of JfrStackTraces by the top frame >> and linked to the StacktraceView for better visualization >> >> Example: >> Screenshot 2021-09-06 at 17 21 42 > > Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: > > fix formatting Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/305 From hirt at openjdk.java.net Tue Sep 7 12:18:39 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 7 Sep 2021 12:18:39 GMT Subject: RFR: 7378: Update platform to 2021-06 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 22:08:14 GMT, Marcus Hirt wrote: > ...and removing old ones. For me, the UI-tests will not start with this PR (on Windows). ------------- PR: https://git.openjdk.java.net/jmc/pull/301 From github.com+348973+cimi at openjdk.java.net Tue Sep 7 12:57:50 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Tue, 7 Sep 2021 12:57:50 GMT Subject: RFR: 7393: Add vanilla Java JSON serializer for IItemCollections Message-ID: ## What is this? This PR adds a JSON serialiser for IItemCollections, with no other library dependencies. This implementation was originally done in #225 with the goal of providing JSON data directly to the browser over a WebSocket. We could use this as a generic representation of events to drive all visualisations we display in JMC since all structures (tree, graph etc) can be constructed from this base format. This would ensure a uniform interface for all visualisations (they could all expect event JSON data). ## Serialized event structure The serialized recording currently looks like this: { "events": [{ "eventType": "", "attributes": { "": "", "": "" } }] } We've previously discussed having a `metadata` section in the JSON file in order to avoid repeating the attribute names - this is not implemented yet and I'd like to understand better how we want it to look like. It would be good to have a consistent representation of the event types and attributes across recordings so i.e. we don't encode them to different symbols and then have the same item represented in different ways. Since the encoding table will be shipped with the serialised items, in practice they can be decoded to the same thing but I'm not sure the benefit is worth the complexity. The only benefit I see for this is having a smaller document size, but we can probably get better compression if we just use zip. ## Testing and benchmarking This PR currently has no tests because I wasn't sure how we want to run them here and what test data I can use. [This project, jmc-json-benchmarks](https://github.com/cimi/jmc-json-benchmarks), has the same code with tests and also has logic to benchmark different JSON serialisation implementations using JMH. While doing the JMH analysis, we found that FastJSON is significantly faster compared to this ad-hoc implementation, but for simplicity we can start with this implementation and replace later if performance becomes an issue. You can see the benchmark results here: https://jmh.morethan.io/?source=https://raw.githubusercontent.com/cimi/jmc-json-benchmarks/master/all-results.json ## Examples of serialised events These examples were taken from the test cases used to validate the implementation, you can see the full test output here: * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/latency_before.json * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/wldf.json (The number of events serialised from the recording was truncated).
EJB_Pool_Manager_Pre_Invoke { "eventType": "http://www.oracle.com/wls/flightrecorder/medium/wls/EJB/EJB_Pool_Manager_Pre_Invoke", "attributes": { "(endTime)": 1384767793251009019, "eventThread": "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'", "stackTrace": { "frames": [{ "name": "weblogic.diagnostics.instrumentation.gathering.FlightRecorderEventHelper#recordStatelessEvent(Lweblogic/diagnostics/instrumentation/DiagnosticMonitor;Lweblogic/diagnostics/instrumentation/JoinPoint;)V", "line": 92, "type": "INTERPRETED" }, { "name": "weblogic.diagnostics.instrumentation.action.FlightRecorderStatelessAction#process(Lweblogic/diagnostics/instrumentation/JoinPoint;)V", "line": 51, "type": "INTERPRETED" }, [... many others ...], { "name": "weblogic.work.ExecuteThread#run()V", "line": 248, "type": "INTERPRETED" }] }, "userID": "", "returnValue": "", "methodName": "preInvoke", "className": "weblogic.ejb.container.manager.StatelessManager", "transactionID": "BEA1-000217F1E993CDB6E1F6", "RCID": null, "RID": null, "ECID": "8ec006a7-30e9-4fac-be7f-716f42d3cbc8-0000001c", "ejbMethodName": null, "ejbName": null, "componentName": null, "applicationName": null, "subsystem": "EJB" }
jdk.PSHeapSummary { "eventType": "jdk.PSHeapSummary", "attributes": { "(endTime)": 1384767779307774408, "gcId": 4, "when": "After GC", "oldSpace:start": 3758096384, "oldSpace:committedEnd": 3937402880, "oldSpace:committedSize": 179306496, "oldSpace:reservedEnd": 4115660800, "oldSpace:reservedSize": 357564416, "oldObjectSpace:start": 3758096384, "oldObjectSpace:end": 3937402880, "oldObjectSpace:used": 50007536, "oldObjectSpace:size": 179306496, "youngSpace:start": 4115660800, "youngSpace:committedEnd": 4294967296, "youngSpace:committedSize": 179306496, "youngSpace:reservedEnd": 4294967296, "youngSpace:reservedSize": 179306496, "edenSpace:start": 4115660800, "edenSpace:end": 4272947200, "edenSpace:used": 0, "edenSpace:size": 157286400, "fromSpace:start": 4272947200, "fromSpace:end": 4283957248, "fromSpace:used": 10977416, "fromSpace:size": 11010048, "toSpace:start": 4283957248, "toSpace:end": 4294967296, "toSpace:used": 0, "toSpace:size": 11010048 }
jdk.NetworkUtilization { "eventType": "jdk.NetworkUtilization", "attributes": { "startTime": 1541771978642206341, "networkInterface": "Hyper-V Virtual Ethernet Adapter #15", "readRate": 3349, "writeRate": 461 } } ------------- Commit messages: - Add JSON serializer test using fixtures from StacktraceTestToolkit - Add vanilla Java JSON serializer for IItemCollections Changes: https://git.openjdk.java.net/jmc/pull/279/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=279&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7393 Stats: 6572 lines in 5 files changed: 6572 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/279.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/279/head:pull/279 PR: https://git.openjdk.java.net/jmc/pull/279 From hirt at openjdk.java.net Tue Sep 7 12:57:51 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Tue, 7 Sep 2021 12:57:51 GMT Subject: RFR: 7393: Add vanilla Java JSON serializer for IItemCollections In-Reply-To: References: Message-ID: On Wed, 21 Jul 2021 16:42:41 GMT, Alex Ciminian wrote: > ## What is this? > > This PR adds a JSON serialiser for IItemCollections, with no other library dependencies. This implementation was originally done in #225 with the goal of providing JSON data directly to the browser over a WebSocket. > > We could use this as a generic representation of events to drive all visualisations we display in JMC since all structures (tree, graph etc) can be constructed from this base format. This would ensure a uniform interface for all visualisations (they could all expect event JSON data). > > ## Serialized event structure > > The serialized recording currently looks like this: > > > { > "events": [{ > "eventType": "", > "attributes": { > "": "", > "": "" > } > }] > } > > > We've previously discussed having a `metadata` section in the JSON file in order to avoid repeating the attribute names - this is not implemented yet and I'd like to understand better how we want it to look like. It would be good to have a consistent representation of the event types and attributes across recordings so i.e. we don't encode them to different symbols and then have the same item represented in different ways. Since the encoding table will be shipped with the serialised items, in practice they can be decoded to the same thing but I'm not sure the benefit is worth the complexity. The only benefit I see for this is having a smaller document size, but we can probably get better compression if we just use zip. > > ## Testing and benchmarking > > This PR currently has no tests because I wasn't sure how we want to run them here and what test data I can use. [This project, jmc-json-benchmarks](https://github.com/cimi/jmc-json-benchmarks), has the same code with tests and also has logic to benchmark different JSON serialisation implementations using JMH. While doing the JMH analysis, we found that FastJSON is significantly faster compared to this ad-hoc implementation, but for simplicity we can start with this implementation and replace later if performance becomes an issue. > > You can see the benchmark results here: https://jmh.morethan.io/?source=https://raw.githubusercontent.com/cimi/jmc-json-benchmarks/master/all-results.json > > ## Examples of serialised events > > These examples were taken from the test cases used to validate the implementation, you can see the full test output here: > > * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/latency_before.json > * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/wldf.json > > (The number of events serialised from the recording was truncated). > >
> EJB_Pool_Manager_Pre_Invoke > > > { > "eventType": "http://www.oracle.com/wls/flightrecorder/medium/wls/EJB/EJB_Pool_Manager_Pre_Invoke", > "attributes": { > "(endTime)": 1384767793251009019, > "eventThread": "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'", > "stackTrace": { > "frames": [{ > "name": "weblogic.diagnostics.instrumentation.gathering.FlightRecorderEventHelper#recordStatelessEvent(Lweblogic/diagnostics/instrumentation/DiagnosticMonitor;Lweblogic/diagnostics/instrumentation/JoinPoint;)V", > "line": 92, > "type": "INTERPRETED" > }, { > "name": "weblogic.diagnostics.instrumentation.action.FlightRecorderStatelessAction#process(Lweblogic/diagnostics/instrumentation/JoinPoint;)V", > "line": 51, > "type": "INTERPRETED" > }, [... many others ...], { > "name": "weblogic.work.ExecuteThread#run()V", > "line": 248, > "type": "INTERPRETED" > }] > }, > "userID": "", > "returnValue": "", > "methodName": "preInvoke", > "className": "weblogic.ejb.container.manager.StatelessManager", > "transactionID": "BEA1-000217F1E993CDB6E1F6", > "RCID": null, > "RID": null, > "ECID": "8ec006a7-30e9-4fac-be7f-716f42d3cbc8-0000001c", > "ejbMethodName": null, > "ejbName": null, > "componentName": null, > "applicationName": null, > "subsystem": "EJB" > } > >
> >
> jdk.PSHeapSummary > > > { > "eventType": "jdk.PSHeapSummary", > "attributes": { > "(endTime)": 1384767779307774408, > "gcId": 4, > "when": "After GC", > "oldSpace:start": 3758096384, > "oldSpace:committedEnd": 3937402880, > "oldSpace:committedSize": 179306496, > "oldSpace:reservedEnd": 4115660800, > "oldSpace:reservedSize": 357564416, > "oldObjectSpace:start": 3758096384, > "oldObjectSpace:end": 3937402880, > "oldObjectSpace:used": 50007536, > "oldObjectSpace:size": 179306496, > "youngSpace:start": 4115660800, > "youngSpace:committedEnd": 4294967296, > "youngSpace:committedSize": 179306496, > "youngSpace:reservedEnd": 4294967296, > "youngSpace:reservedSize": 179306496, > "edenSpace:start": 4115660800, > "edenSpace:end": 4272947200, > "edenSpace:used": 0, > "edenSpace:size": 157286400, > "fromSpace:start": 4272947200, > "fromSpace:end": 4283957248, > "fromSpace:used": 10977416, > "fromSpace:size": 11010048, > "toSpace:start": 4283957248, > "toSpace:end": 4294967296, > "toSpace:used": 0, > "toSpace:size": 11010048 > } > >
> >
> jdk.NetworkUtilization > > > { > "eventType": "jdk.NetworkUtilization", > "attributes": { > "startTime": 1541771978642206341, > "networkInterface": "Hyper-V Virtual Ethernet Adapter #15", > "readRate": 3349, > "writeRate": 461 > } > } Changes requested by hirt (Lead). HI Cimi! For the tests, simply see flightrecorder.serializers.test. Even a few trivial tests validating the expected results is better than nothing. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/IItemCollectionJsonSerializer.java line 1: > 1: package org.openjdk.jmc.flightrecorder.serializers.json; Lacks standard JMC license header (Oracle + Datadog). core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/JsonWriter.java line 1: > 1: package org.openjdk.jmc.flightrecorder.serializers.json; Lacks standard JMC license header (Oracle + Datadog). core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 1: > 1: package org.openjdk.jmc.flightrecorder.serializers.json; Lacks standard JMC license header (Oracle + Datadog). core/tests/org.openjdk.jmc.flightrecorder.serializers.test/src/test/java/org/openjdk/jmc/flightrecorder/serializers/json/test/IItemCollectionJsonSerializerTest.java line 1: > 1: package org.openjdk.jmc.flightrecorder.serializers.json.test; Lacks standard JMC license header (Oracle + Datadog). ------------- PR: https://git.openjdk.java.net/jmc/pull/279 From jpbempel at openjdk.java.net Tue Sep 7 13:00:39 2021 From: jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Tue, 7 Sep 2021 13:00:39 GMT Subject: Integrated: 7332: Show stacktraces for constant values from stacktrace pool In-Reply-To: References: Message-ID: On Mon, 6 Sep 2021 15:24:31 GMT, Jean-Philippe Bempel wrote: > Replace the default Object.ToString of JfrStackTraces by the top frame > and linked to the StacktraceView for better visualization > > Example: > Screenshot 2021-09-06 at 17 21 42 This pull request has now been integrated. Changeset: ff29931f Author: Jean-Philippe Bempel URL: https://git.openjdk.java.net/jmc/commit/ff29931ff5013afc086fba89e4444363924aa8b9 Stats: 26 lines in 2 files changed: 23 ins; 1 del; 2 mod 7332: Show stacktraces for constant values from stacktrace pool Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/305 From github.com+348973+cimi at openjdk.java.net Tue Sep 7 15:21:00 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Tue, 7 Sep 2021 15:21:00 GMT Subject: RFR: 7393: Add vanilla Java JSON serializer for IItemCollections [v2] In-Reply-To: References: Message-ID: > ## What is this? > > This PR adds a JSON serialiser for IItemCollections, with no other library dependencies. This implementation was originally done in #225 with the goal of providing JSON data directly to the browser over a WebSocket. > > We could use this as a generic representation of events to drive all visualisations we display in JMC since all structures (tree, graph etc) can be constructed from this base format. This would ensure a uniform interface for all visualisations (they could all expect event JSON data). > > ## Serialized event structure > > The serialized recording currently looks like this: > > > { > "events": [{ > "eventType": "", > "attributes": { > "": "", > "": "" > } > }] > } > > > We've previously discussed having a `metadata` section in the JSON file in order to avoid repeating the attribute names - this is not implemented yet and I'd like to understand better how we want it to look like. It would be good to have a consistent representation of the event types and attributes across recordings so i.e. we don't encode them to different symbols and then have the same item represented in different ways. Since the encoding table will be shipped with the serialised items, in practice they can be decoded to the same thing but I'm not sure the benefit is worth the complexity. The only benefit I see for this is having a smaller document size, but we can probably get better compression if we just use zip. > > ## Testing and benchmarking > > This PR currently has no tests because I wasn't sure how we want to run them here and what test data I can use. [This project, jmc-json-benchmarks](https://github.com/cimi/jmc-json-benchmarks), has the same code with tests and also has logic to benchmark different JSON serialisation implementations using JMH. While doing the JMH analysis, we found that FastJSON is significantly faster compared to this ad-hoc implementation, but for simplicity we can start with this implementation and replace later if performance becomes an issue. > > You can see the benchmark results here: https://jmh.morethan.io/?source=https://raw.githubusercontent.com/cimi/jmc-json-benchmarks/master/all-results.json > > ## Examples of serialised events > > These examples were taken from the test cases used to validate the implementation, you can see the full test output here: > > * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/latency_before.json > * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/wldf.json > > (The number of events serialised from the recording was truncated). > >
> EJB_Pool_Manager_Pre_Invoke > > > { > "eventType": "http://www.oracle.com/wls/flightrecorder/medium/wls/EJB/EJB_Pool_Manager_Pre_Invoke", > "attributes": { > "(endTime)": 1384767793251009019, > "eventThread": "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'", > "stackTrace": { > "frames": [{ > "name": "weblogic.diagnostics.instrumentation.gathering.FlightRecorderEventHelper#recordStatelessEvent(Lweblogic/diagnostics/instrumentation/DiagnosticMonitor;Lweblogic/diagnostics/instrumentation/JoinPoint;)V", > "line": 92, > "type": "INTERPRETED" > }, { > "name": "weblogic.diagnostics.instrumentation.action.FlightRecorderStatelessAction#process(Lweblogic/diagnostics/instrumentation/JoinPoint;)V", > "line": 51, > "type": "INTERPRETED" > }, [... many others ...], { > "name": "weblogic.work.ExecuteThread#run()V", > "line": 248, > "type": "INTERPRETED" > }] > }, > "userID": "", > "returnValue": "", > "methodName": "preInvoke", > "className": "weblogic.ejb.container.manager.StatelessManager", > "transactionID": "BEA1-000217F1E993CDB6E1F6", > "RCID": null, > "RID": null, > "ECID": "8ec006a7-30e9-4fac-be7f-716f42d3cbc8-0000001c", > "ejbMethodName": null, > "ejbName": null, > "componentName": null, > "applicationName": null, > "subsystem": "EJB" > } > >
> >
> jdk.PSHeapSummary > > > { > "eventType": "jdk.PSHeapSummary", > "attributes": { > "(endTime)": 1384767779307774408, > "gcId": 4, > "when": "After GC", > "oldSpace:start": 3758096384, > "oldSpace:committedEnd": 3937402880, > "oldSpace:committedSize": 179306496, > "oldSpace:reservedEnd": 4115660800, > "oldSpace:reservedSize": 357564416, > "oldObjectSpace:start": 3758096384, > "oldObjectSpace:end": 3937402880, > "oldObjectSpace:used": 50007536, > "oldObjectSpace:size": 179306496, > "youngSpace:start": 4115660800, > "youngSpace:committedEnd": 4294967296, > "youngSpace:committedSize": 179306496, > "youngSpace:reservedEnd": 4294967296, > "youngSpace:reservedSize": 179306496, > "edenSpace:start": 4115660800, > "edenSpace:end": 4272947200, > "edenSpace:used": 0, > "edenSpace:size": 157286400, > "fromSpace:start": 4272947200, > "fromSpace:end": 4283957248, > "fromSpace:used": 10977416, > "fromSpace:size": 11010048, > "toSpace:start": 4283957248, > "toSpace:end": 4294967296, > "toSpace:used": 0, > "toSpace:size": 11010048 > } > >
> >
> jdk.NetworkUtilization > > > { > "eventType": "jdk.NetworkUtilization", > "attributes": { > "startTime": 1541771978642206341, > "networkInterface": "Hyper-V Virtual Ethernet Adapter #15", > "readRate": 3349, > "writeRate": 461 > } > } Alex Ciminian has updated the pull request incrementally with one additional commit since the last revision: Add JMC license header to new classes ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/279/files - new: https://git.openjdk.java.net/jmc/pull/279/files/ed11c6bd..11963a68 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=279&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=279&range=00-01 Stats: 132 lines in 4 files changed: 132 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jmc/pull/279.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/279/head:pull/279 PR: https://git.openjdk.java.net/jmc/pull/279 From jpbempel at openjdk.java.net Wed Sep 8 08:33:06 2021 From: jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Wed, 8 Sep 2021 08:33:06 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 21:30:09 GMT, Alex Macdonald wrote: > This PR addresses JMC-7307 [[0]](https://bugs.openjdk.java.net/browse/JMC-7307), in which it would be helpful to have `flightrecorder.configuration` distributed in jmc core. > > `flightrecorder.configuration` itself is a pretty straightforward movement of code, as it doesn't have any dependencies. Having said that, there are some flightrecorder-configuration-related classes in `controlpanel.ui` which would be nice to have in core as well, and would probably do well in `flightrecorder.configuration`. This includes VolatileStorageDelegate, and the 12 classes in `configuration.model.xml`. The `controlpanel.ui.configuration` unit tests can also come over to core, because they only tested the model xml code anyways. > > So in total, we're looking at `flightrecorder.configuration` and the former `controlpanel.ui.configuration` test coming over to core, and the following classes: > - org.openjdk.jmc.flightrecorder.configuration.model.VolatileStorageDelegate > - org.openjdk.jmc.flightrecorder.configuration.model.xml.IXMLValidator > - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCGrammar > - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCXMLValidator > - org.openjdk.jmc.flightrecorder.configuration.model.xml.PrettyPrinter > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttribute > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttributeInstance > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLModel > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNode > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNodeType > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTag > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTagInstance > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLValidationResult > > [0] https://bugs.openjdk.java.net/browse/JMC-7307 Marked as reviewed by jpbempel (Committer). ------------- PR: https://git.openjdk.java.net/jmc/pull/299 From jpbempel at openjdk.java.net Wed Sep 8 08:52:09 2021 From: jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Wed, 8 Sep 2021 08:52:09 GMT Subject: RFR: 7393: Add vanilla Java JSON serializer for IItemCollections [v2] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 15:21:00 GMT, Alex Ciminian wrote: >> ## What is this? >> >> This PR adds a JSON serialiser for IItemCollections, with no other library dependencies. This implementation was originally done in #225 with the goal of providing JSON data directly to the browser over a WebSocket. >> >> We could use this as a generic representation of events to drive all visualisations we display in JMC since all structures (tree, graph etc) can be constructed from this base format. This would ensure a uniform interface for all visualisations (they could all expect event JSON data). >> >> ## Serialized event structure >> >> The serialized recording currently looks like this: >> >> >> { >> "events": [{ >> "eventType": "", >> "attributes": { >> "": "", >> "": "" >> } >> }] >> } >> >> >> We've previously discussed having a `metadata` section in the JSON file in order to avoid repeating the attribute names - this is not implemented yet and I'd like to understand better how we want it to look like. It would be good to have a consistent representation of the event types and attributes across recordings so i.e. we don't encode them to different symbols and then have the same item represented in different ways. Since the encoding table will be shipped with the serialised items, in practice they can be decoded to the same thing but I'm not sure the benefit is worth the complexity. The only benefit I see for this is having a smaller document size, but we can probably get better compression if we just use zip. >> >> ## Testing and benchmarking >> >> This PR currently has no tests because I wasn't sure how we want to run them here and what test data I can use. [This project, jmc-json-benchmarks](https://github.com/cimi/jmc-json-benchmarks), has the same code with tests and also has logic to benchmark different JSON serialisation implementations using JMH. While doing the JMH analysis, we found that FastJSON is significantly faster compared to this ad-hoc implementation, but for simplicity we can start with this implementation and replace later if performance becomes an issue. >> >> You can see the benchmark results here: https://jmh.morethan.io/?source=https://raw.githubusercontent.com/cimi/jmc-json-benchmarks/master/all-results.json >> >> ## Examples of serialised events >> >> These examples were taken from the test cases used to validate the implementation, you can see the full test output here: >> >> * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/latency_before.json >> * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/wldf.json >> >> (The number of events serialised from the recording was truncated). >> >>
>> EJB_Pool_Manager_Pre_Invoke >> >> >> { >> "eventType": "http://www.oracle.com/wls/flightrecorder/medium/wls/EJB/EJB_Pool_Manager_Pre_Invoke", >> "attributes": { >> "(endTime)": 1384767793251009019, >> "eventThread": "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'", >> "stackTrace": { >> "frames": [{ >> "name": "weblogic.diagnostics.instrumentation.gathering.FlightRecorderEventHelper#recordStatelessEvent(Lweblogic/diagnostics/instrumentation/DiagnosticMonitor;Lweblogic/diagnostics/instrumentation/JoinPoint;)V", >> "line": 92, >> "type": "INTERPRETED" >> }, { >> "name": "weblogic.diagnostics.instrumentation.action.FlightRecorderStatelessAction#process(Lweblogic/diagnostics/instrumentation/JoinPoint;)V", >> "line": 51, >> "type": "INTERPRETED" >> }, [... many others ...], { >> "name": "weblogic.work.ExecuteThread#run()V", >> "line": 248, >> "type": "INTERPRETED" >> }] >> }, >> "userID": "", >> "returnValue": "", >> "methodName": "preInvoke", >> "className": "weblogic.ejb.container.manager.StatelessManager", >> "transactionID": "BEA1-000217F1E993CDB6E1F6", >> "RCID": null, >> "RID": null, >> "ECID": "8ec006a7-30e9-4fac-be7f-716f42d3cbc8-0000001c", >> "ejbMethodName": null, >> "ejbName": null, >> "componentName": null, >> "applicationName": null, >> "subsystem": "EJB" >> } >> >>
>> >>
>> jdk.PSHeapSummary >> >> >> { >> "eventType": "jdk.PSHeapSummary", >> "attributes": { >> "(endTime)": 1384767779307774408, >> "gcId": 4, >> "when": "After GC", >> "oldSpace:start": 3758096384, >> "oldSpace:committedEnd": 3937402880, >> "oldSpace:committedSize": 179306496, >> "oldSpace:reservedEnd": 4115660800, >> "oldSpace:reservedSize": 357564416, >> "oldObjectSpace:start": 3758096384, >> "oldObjectSpace:end": 3937402880, >> "oldObjectSpace:used": 50007536, >> "oldObjectSpace:size": 179306496, >> "youngSpace:start": 4115660800, >> "youngSpace:committedEnd": 4294967296, >> "youngSpace:committedSize": 179306496, >> "youngSpace:reservedEnd": 4294967296, >> "youngSpace:reservedSize": 179306496, >> "edenSpace:start": 4115660800, >> "edenSpace:end": 4272947200, >> "edenSpace:used": 0, >> "edenSpace:size": 157286400, >> "fromSpace:start": 4272947200, >> "fromSpace:end": 4283957248, >> "fromSpace:used": 10977416, >> "fromSpace:size": 11010048, >> "toSpace:start": 4283957248, >> "toSpace:end": 4294967296, >> "toSpace:used": 0, >> "toSpace:size": 11010048 >> } >> >>
>> >>
>> jdk.NetworkUtilization >> >> >> { >> "eventType": "jdk.NetworkUtilization", >> "attributes": { >> "startTime": 1541771978642206341, >> "networkInterface": "Hyper-V Virtual Ethernet Adapter #15", >> "readRate": 3349, >> "writeRate": 461 >> } >> } > > Alex Ciminian has updated the pull request incrementally with one additional commit since the last revision: > > Add JMC license header to new classes LGTM indentation is 8 in those files, while rest of JMC seems 4. I don't mind, just noticing... ------------- Marked as reviewed by jpbempel (Committer). PR: https://git.openjdk.java.net/jmc/pull/279 From hirt at openjdk.java.net Wed Sep 8 21:13:10 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Wed, 8 Sep 2021 21:13:10 GMT Subject: RFR: 7393: Add vanilla Java JSON serializer for IItemCollections [v2] In-Reply-To: References: Message-ID: On Tue, 7 Sep 2021 15:21:00 GMT, Alex Ciminian wrote: >> ## What is this? >> >> This PR adds a JSON serialiser for IItemCollections, with no other library dependencies. This implementation was originally done in #225 with the goal of providing JSON data directly to the browser over a WebSocket. >> >> We could use this as a generic representation of events to drive all visualisations we display in JMC since all structures (tree, graph etc) can be constructed from this base format. This would ensure a uniform interface for all visualisations (they could all expect event JSON data). >> >> ## Serialized event structure >> >> The serialized recording currently looks like this: >> >> >> { >> "events": [{ >> "eventType": "", >> "attributes": { >> "": "", >> "": "" >> } >> }] >> } >> >> >> We've previously discussed having a `metadata` section in the JSON file in order to avoid repeating the attribute names - this is not implemented yet and I'd like to understand better how we want it to look like. It would be good to have a consistent representation of the event types and attributes across recordings so i.e. we don't encode them to different symbols and then have the same item represented in different ways. Since the encoding table will be shipped with the serialised items, in practice they can be decoded to the same thing but I'm not sure the benefit is worth the complexity. The only benefit I see for this is having a smaller document size, but we can probably get better compression if we just use zip. >> >> ## Testing and benchmarking >> >> This PR currently has no tests because I wasn't sure how we want to run them here and what test data I can use. [This project, jmc-json-benchmarks](https://github.com/cimi/jmc-json-benchmarks), has the same code with tests and also has logic to benchmark different JSON serialisation implementations using JMH. While doing the JMH analysis, we found that FastJSON is significantly faster compared to this ad-hoc implementation, but for simplicity we can start with this implementation and replace later if performance becomes an issue. >> >> You can see the benchmark results here: https://jmh.morethan.io/?source=https://raw.githubusercontent.com/cimi/jmc-json-benchmarks/master/all-results.json >> >> ## Examples of serialised events >> >> These examples were taken from the test cases used to validate the implementation, you can see the full test output here: >> >> * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/latency_before.json >> * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/wldf.json >> >> (The number of events serialised from the recording was truncated). >> >>
>> EJB_Pool_Manager_Pre_Invoke >> >> >> { >> "eventType": "http://www.oracle.com/wls/flightrecorder/medium/wls/EJB/EJB_Pool_Manager_Pre_Invoke", >> "attributes": { >> "(endTime)": 1384767793251009019, >> "eventThread": "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'", >> "stackTrace": { >> "frames": [{ >> "name": "weblogic.diagnostics.instrumentation.gathering.FlightRecorderEventHelper#recordStatelessEvent(Lweblogic/diagnostics/instrumentation/DiagnosticMonitor;Lweblogic/diagnostics/instrumentation/JoinPoint;)V", >> "line": 92, >> "type": "INTERPRETED" >> }, { >> "name": "weblogic.diagnostics.instrumentation.action.FlightRecorderStatelessAction#process(Lweblogic/diagnostics/instrumentation/JoinPoint;)V", >> "line": 51, >> "type": "INTERPRETED" >> }, [... many others ...], { >> "name": "weblogic.work.ExecuteThread#run()V", >> "line": 248, >> "type": "INTERPRETED" >> }] >> }, >> "userID": "", >> "returnValue": "", >> "methodName": "preInvoke", >> "className": "weblogic.ejb.container.manager.StatelessManager", >> "transactionID": "BEA1-000217F1E993CDB6E1F6", >> "RCID": null, >> "RID": null, >> "ECID": "8ec006a7-30e9-4fac-be7f-716f42d3cbc8-0000001c", >> "ejbMethodName": null, >> "ejbName": null, >> "componentName": null, >> "applicationName": null, >> "subsystem": "EJB" >> } >> >>
>> >>
>> jdk.PSHeapSummary >> >> >> { >> "eventType": "jdk.PSHeapSummary", >> "attributes": { >> "(endTime)": 1384767779307774408, >> "gcId": 4, >> "when": "After GC", >> "oldSpace:start": 3758096384, >> "oldSpace:committedEnd": 3937402880, >> "oldSpace:committedSize": 179306496, >> "oldSpace:reservedEnd": 4115660800, >> "oldSpace:reservedSize": 357564416, >> "oldObjectSpace:start": 3758096384, >> "oldObjectSpace:end": 3937402880, >> "oldObjectSpace:used": 50007536, >> "oldObjectSpace:size": 179306496, >> "youngSpace:start": 4115660800, >> "youngSpace:committedEnd": 4294967296, >> "youngSpace:committedSize": 179306496, >> "youngSpace:reservedEnd": 4294967296, >> "youngSpace:reservedSize": 179306496, >> "edenSpace:start": 4115660800, >> "edenSpace:end": 4272947200, >> "edenSpace:used": 0, >> "edenSpace:size": 157286400, >> "fromSpace:start": 4272947200, >> "fromSpace:end": 4283957248, >> "fromSpace:used": 10977416, >> "fromSpace:size": 11010048, >> "toSpace:start": 4283957248, >> "toSpace:end": 4294967296, >> "toSpace:used": 0, >> "toSpace:size": 11010048 >> } >> >>
>> >>
>> jdk.NetworkUtilization >> >> >> { >> "eventType": "jdk.NetworkUtilization", >> "attributes": { >> "startTime": 1541771978642206341, >> "networkInterface": "Hyper-V Virtual Ethernet Adapter #15", >> "readRate": 3349, >> "writeRate": 461 >> } >> } > > Alex Ciminian has updated the pull request incrementally with one additional commit since the last revision: > > Add JMC license header to new classes Changes requested by hirt (Lead). core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 133: > 131: } > 132: > 133: final protected int getColumn() { Modifier order. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 144: > 142: } > 143: > 144: final public void writeIndent() { Modifier order. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 149: > 147: } > 148: > 149: final public void writeln() { Modifier order. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 154: > 152: } > 153: > 154: final public void write(String ... texts) { Modifier order. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 160: > 158: } > 159: > 160: final public void writeAsString(Object o) { Modifier order. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 164: > 162: } > 163: > 164: final public void write(String text) { Modifier order. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 169: > 167: } > 168: > 169: final public void write(char c) { Modifier order. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 174: > 172: } > 173: > 174: final public void write(int value) { Modifier order. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 178: > 176: } > 177: > 178: final public void indent() { Modifier order. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 183: > 181: } > 182: > 183: final public void retract() { Modifier order. core/org.openjdk.jmc.flightrecorder.serializers/src/main/java/org/openjdk/jmc/flightrecorder/serializers/json/StructuredWriter.java line 188: > 186: } > 187: > 188: final public void writeln(String text) { Modifier order. ------------- PR: https://git.openjdk.java.net/jmc/pull/279 From hirt at openjdk.java.net Thu Sep 9 08:25:01 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 9 Sep 2021 08:25:01 GMT Subject: RFR: 7393: Add vanilla Java JSON serializer for IItemCollections [v2] In-Reply-To: References: Message-ID: On Wed, 8 Sep 2021 08:49:38 GMT, Jean-Philippe Bempel wrote: > LGTM > indentation is 8 in those files, while rest of JMC seems 4. > I don't mind, just noticing... Indentation is one tab per indentation step. Tip is to always use the Mission Control formatting settings. ------------- PR: https://git.openjdk.java.net/jmc/pull/279 From github.com+348973+cimi at openjdk.java.net Thu Sep 9 08:58:30 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Thu, 9 Sep 2021 08:58:30 GMT Subject: RFR: 7393: Add vanilla Java JSON serializer for IItemCollections [v3] In-Reply-To: References: Message-ID: > ## What is this? > > This PR adds a JSON serialiser for IItemCollections, with no other library dependencies. This implementation was originally done in #225 with the goal of providing JSON data directly to the browser over a WebSocket. > > We could use this as a generic representation of events to drive all visualisations we display in JMC since all structures (tree, graph etc) can be constructed from this base format. This would ensure a uniform interface for all visualisations (they could all expect event JSON data). > > ## Serialized event structure > > The serialized recording currently looks like this: > > > { > "events": [{ > "eventType": "", > "attributes": { > "": "", > "": "" > } > }] > } > > > We've previously discussed having a `metadata` section in the JSON file in order to avoid repeating the attribute names - this is not implemented yet and I'd like to understand better how we want it to look like. It would be good to have a consistent representation of the event types and attributes across recordings so i.e. we don't encode them to different symbols and then have the same item represented in different ways. Since the encoding table will be shipped with the serialised items, in practice they can be decoded to the same thing but I'm not sure the benefit is worth the complexity. The only benefit I see for this is having a smaller document size, but we can probably get better compression if we just use zip. > > ## Testing and benchmarking > > This PR currently has no tests because I wasn't sure how we want to run them here and what test data I can use. [This project, jmc-json-benchmarks](https://github.com/cimi/jmc-json-benchmarks), has the same code with tests and also has logic to benchmark different JSON serialisation implementations using JMH. While doing the JMH analysis, we found that FastJSON is significantly faster compared to this ad-hoc implementation, but for simplicity we can start with this implementation and replace later if performance becomes an issue. > > You can see the benchmark results here: https://jmh.morethan.io/?source=https://raw.githubusercontent.com/cimi/jmc-json-benchmarks/master/all-results.json > > ## Examples of serialised events > > These examples were taken from the test cases used to validate the implementation, you can see the full test output here: > > * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/latency_before.json > * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/wldf.json > > (The number of events serialised from the recording was truncated). > >
> EJB_Pool_Manager_Pre_Invoke > > > { > "eventType": "http://www.oracle.com/wls/flightrecorder/medium/wls/EJB/EJB_Pool_Manager_Pre_Invoke", > "attributes": { > "(endTime)": 1384767793251009019, > "eventThread": "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'", > "stackTrace": { > "frames": [{ > "name": "weblogic.diagnostics.instrumentation.gathering.FlightRecorderEventHelper#recordStatelessEvent(Lweblogic/diagnostics/instrumentation/DiagnosticMonitor;Lweblogic/diagnostics/instrumentation/JoinPoint;)V", > "line": 92, > "type": "INTERPRETED" > }, { > "name": "weblogic.diagnostics.instrumentation.action.FlightRecorderStatelessAction#process(Lweblogic/diagnostics/instrumentation/JoinPoint;)V", > "line": 51, > "type": "INTERPRETED" > }, [... many others ...], { > "name": "weblogic.work.ExecuteThread#run()V", > "line": 248, > "type": "INTERPRETED" > }] > }, > "userID": "", > "returnValue": "", > "methodName": "preInvoke", > "className": "weblogic.ejb.container.manager.StatelessManager", > "transactionID": "BEA1-000217F1E993CDB6E1F6", > "RCID": null, > "RID": null, > "ECID": "8ec006a7-30e9-4fac-be7f-716f42d3cbc8-0000001c", > "ejbMethodName": null, > "ejbName": null, > "componentName": null, > "applicationName": null, > "subsystem": "EJB" > } > >
> >
> jdk.PSHeapSummary > > > { > "eventType": "jdk.PSHeapSummary", > "attributes": { > "(endTime)": 1384767779307774408, > "gcId": 4, > "when": "After GC", > "oldSpace:start": 3758096384, > "oldSpace:committedEnd": 3937402880, > "oldSpace:committedSize": 179306496, > "oldSpace:reservedEnd": 4115660800, > "oldSpace:reservedSize": 357564416, > "oldObjectSpace:start": 3758096384, > "oldObjectSpace:end": 3937402880, > "oldObjectSpace:used": 50007536, > "oldObjectSpace:size": 179306496, > "youngSpace:start": 4115660800, > "youngSpace:committedEnd": 4294967296, > "youngSpace:committedSize": 179306496, > "youngSpace:reservedEnd": 4294967296, > "youngSpace:reservedSize": 179306496, > "edenSpace:start": 4115660800, > "edenSpace:end": 4272947200, > "edenSpace:used": 0, > "edenSpace:size": 157286400, > "fromSpace:start": 4272947200, > "fromSpace:end": 4283957248, > "fromSpace:used": 10977416, > "fromSpace:size": 11010048, > "toSpace:start": 4283957248, > "toSpace:end": 4294967296, > "toSpace:used": 0, > "toSpace:size": 11010048 > } > >
> >
> jdk.NetworkUtilization > > > { > "eventType": "jdk.NetworkUtilization", > "attributes": { > "startTime": 1541771978642206341, > "networkInterface": "Hyper-V Virtual Ethernet Adapter #15", > "readRate": 3349, > "writeRate": 461 > } > } Alex Ciminian has updated the pull request incrementally with one additional commit since the last revision: Fix modifier order in StructuredWriter methods ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/279/files - new: https://git.openjdk.java.net/jmc/pull/279/files/11963a68..9b8ea3ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=279&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=279&range=01-02 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jmc/pull/279.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/279/head:pull/279 PR: https://git.openjdk.java.net/jmc/pull/279 From hirt at openjdk.java.net Thu Sep 9 11:27:04 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 9 Sep 2021 11:27:04 GMT Subject: RFR: 7393: Add vanilla Java JSON serializer for IItemCollections [v3] In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 08:58:30 GMT, Alex Ciminian wrote: >> ## What is this? >> >> This PR adds a JSON serialiser for IItemCollections, with no other library dependencies. This implementation was originally done in #225 with the goal of providing JSON data directly to the browser over a WebSocket. >> >> We could use this as a generic representation of events to drive all visualisations we display in JMC since all structures (tree, graph etc) can be constructed from this base format. This would ensure a uniform interface for all visualisations (they could all expect event JSON data). >> >> ## Serialized event structure >> >> The serialized recording currently looks like this: >> >> >> { >> "events": [{ >> "eventType": "", >> "attributes": { >> "": "", >> "": "" >> } >> }] >> } >> >> >> We've previously discussed having a `metadata` section in the JSON file in order to avoid repeating the attribute names - this is not implemented yet and I'd like to understand better how we want it to look like. It would be good to have a consistent representation of the event types and attributes across recordings so i.e. we don't encode them to different symbols and then have the same item represented in different ways. Since the encoding table will be shipped with the serialised items, in practice they can be decoded to the same thing but I'm not sure the benefit is worth the complexity. The only benefit I see for this is having a smaller document size, but we can probably get better compression if we just use zip. >> >> ## Testing and benchmarking >> >> This PR currently has no tests because I wasn't sure how we want to run them here and what test data I can use. [This project, jmc-json-benchmarks](https://github.com/cimi/jmc-json-benchmarks), has the same code with tests and also has logic to benchmark different JSON serialisation implementations using JMH. While doing the JMH analysis, we found that FastJSON is significantly faster compared to this ad-hoc implementation, but for simplicity we can start with this implementation and replace later if performance becomes an issue. >> >> You can see the benchmark results here: https://jmh.morethan.io/?source=https://raw.githubusercontent.com/cimi/jmc-json-benchmarks/master/all-results.json >> >> ## Examples of serialised events >> >> These examples were taken from the test cases used to validate the implementation, you can see the full test output here: >> >> * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/latency_before.json >> * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/wldf.json >> >> (The number of events serialised from the recording was truncated). >> >>
>> EJB_Pool_Manager_Pre_Invoke >> >> >> { >> "eventType": "http://www.oracle.com/wls/flightrecorder/medium/wls/EJB/EJB_Pool_Manager_Pre_Invoke", >> "attributes": { >> "(endTime)": 1384767793251009019, >> "eventThread": "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'", >> "stackTrace": { >> "frames": [{ >> "name": "weblogic.diagnostics.instrumentation.gathering.FlightRecorderEventHelper#recordStatelessEvent(Lweblogic/diagnostics/instrumentation/DiagnosticMonitor;Lweblogic/diagnostics/instrumentation/JoinPoint;)V", >> "line": 92, >> "type": "INTERPRETED" >> }, { >> "name": "weblogic.diagnostics.instrumentation.action.FlightRecorderStatelessAction#process(Lweblogic/diagnostics/instrumentation/JoinPoint;)V", >> "line": 51, >> "type": "INTERPRETED" >> }, [... many others ...], { >> "name": "weblogic.work.ExecuteThread#run()V", >> "line": 248, >> "type": "INTERPRETED" >> }] >> }, >> "userID": "", >> "returnValue": "", >> "methodName": "preInvoke", >> "className": "weblogic.ejb.container.manager.StatelessManager", >> "transactionID": "BEA1-000217F1E993CDB6E1F6", >> "RCID": null, >> "RID": null, >> "ECID": "8ec006a7-30e9-4fac-be7f-716f42d3cbc8-0000001c", >> "ejbMethodName": null, >> "ejbName": null, >> "componentName": null, >> "applicationName": null, >> "subsystem": "EJB" >> } >> >>
>> >>
>> jdk.PSHeapSummary >> >> >> { >> "eventType": "jdk.PSHeapSummary", >> "attributes": { >> "(endTime)": 1384767779307774408, >> "gcId": 4, >> "when": "After GC", >> "oldSpace:start": 3758096384, >> "oldSpace:committedEnd": 3937402880, >> "oldSpace:committedSize": 179306496, >> "oldSpace:reservedEnd": 4115660800, >> "oldSpace:reservedSize": 357564416, >> "oldObjectSpace:start": 3758096384, >> "oldObjectSpace:end": 3937402880, >> "oldObjectSpace:used": 50007536, >> "oldObjectSpace:size": 179306496, >> "youngSpace:start": 4115660800, >> "youngSpace:committedEnd": 4294967296, >> "youngSpace:committedSize": 179306496, >> "youngSpace:reservedEnd": 4294967296, >> "youngSpace:reservedSize": 179306496, >> "edenSpace:start": 4115660800, >> "edenSpace:end": 4272947200, >> "edenSpace:used": 0, >> "edenSpace:size": 157286400, >> "fromSpace:start": 4272947200, >> "fromSpace:end": 4283957248, >> "fromSpace:used": 10977416, >> "fromSpace:size": 11010048, >> "toSpace:start": 4283957248, >> "toSpace:end": 4294967296, >> "toSpace:used": 0, >> "toSpace:size": 11010048 >> } >> >>
>> >>
>> jdk.NetworkUtilization >> >> >> { >> "eventType": "jdk.NetworkUtilization", >> "attributes": { >> "startTime": 1541771978642206341, >> "networkInterface": "Hyper-V Virtual Ethernet Adapter #15", >> "readRate": 3349, >> "writeRate": 461 >> } >> } > > Alex Ciminian has updated the pull request incrementally with one additional commit since the last revision: > > Fix modifier order in StructuredWriter methods Marked as reviewed by hirt (Lead). ------------- PR: https://git.openjdk.java.net/jmc/pull/279 From hirt at openjdk.java.net Thu Sep 9 11:41:02 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 9 Sep 2021 11:41:02 GMT Subject: RFR: 7393: Add vanilla Java JSON serializer for IItemCollections [v3] In-Reply-To: References: Message-ID: <8CM_pBSE8sBQu9eNNqnnSwz_2UdTQxWiWLmDjUZ7P1A=.2a190ce6-315d-45c7-9a96-fc1fbfbc96e2@github.com> On Thu, 9 Sep 2021 08:58:30 GMT, Alex Ciminian wrote: >> ## What is this? >> >> This PR adds a JSON serialiser for IItemCollections, with no other library dependencies. This implementation was originally done in #225 with the goal of providing JSON data directly to the browser over a WebSocket. >> >> We could use this as a generic representation of events to drive all visualisations we display in JMC since all structures (tree, graph etc) can be constructed from this base format. This would ensure a uniform interface for all visualisations (they could all expect event JSON data). >> >> ## Serialized event structure >> >> The serialized recording currently looks like this: >> >> >> { >> "events": [{ >> "eventType": "", >> "attributes": { >> "": "", >> "": "" >> } >> }] >> } >> >> >> We've previously discussed having a `metadata` section in the JSON file in order to avoid repeating the attribute names - this is not implemented yet and I'd like to understand better how we want it to look like. It would be good to have a consistent representation of the event types and attributes across recordings so i.e. we don't encode them to different symbols and then have the same item represented in different ways. Since the encoding table will be shipped with the serialised items, in practice they can be decoded to the same thing but I'm not sure the benefit is worth the complexity. The only benefit I see for this is having a smaller document size, but we can probably get better compression if we just use zip. >> >> ## Testing and benchmarking >> >> This PR currently has no tests because I wasn't sure how we want to run them here and what test data I can use. [This project, jmc-json-benchmarks](https://github.com/cimi/jmc-json-benchmarks), has the same code with tests and also has logic to benchmark different JSON serialisation implementations using JMH. While doing the JMH analysis, we found that FastJSON is significantly faster compared to this ad-hoc implementation, but for simplicity we can start with this implementation and replace later if performance becomes an issue. >> >> You can see the benchmark results here: https://jmh.morethan.io/?source=https://raw.githubusercontent.com/cimi/jmc-json-benchmarks/master/all-results.json >> >> ## Examples of serialised events >> >> These examples were taken from the test cases used to validate the implementation, you can see the full test output here: >> >> * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/latency_before.json >> * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/wldf.json >> >> (The number of events serialised from the recording was truncated). >> >>
>> EJB_Pool_Manager_Pre_Invoke >> >> >> { >> "eventType": "http://www.oracle.com/wls/flightrecorder/medium/wls/EJB/EJB_Pool_Manager_Pre_Invoke", >> "attributes": { >> "(endTime)": 1384767793251009019, >> "eventThread": "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'", >> "stackTrace": { >> "frames": [{ >> "name": "weblogic.diagnostics.instrumentation.gathering.FlightRecorderEventHelper#recordStatelessEvent(Lweblogic/diagnostics/instrumentation/DiagnosticMonitor;Lweblogic/diagnostics/instrumentation/JoinPoint;)V", >> "line": 92, >> "type": "INTERPRETED" >> }, { >> "name": "weblogic.diagnostics.instrumentation.action.FlightRecorderStatelessAction#process(Lweblogic/diagnostics/instrumentation/JoinPoint;)V", >> "line": 51, >> "type": "INTERPRETED" >> }, [... many others ...], { >> "name": "weblogic.work.ExecuteThread#run()V", >> "line": 248, >> "type": "INTERPRETED" >> }] >> }, >> "userID": "", >> "returnValue": "", >> "methodName": "preInvoke", >> "className": "weblogic.ejb.container.manager.StatelessManager", >> "transactionID": "BEA1-000217F1E993CDB6E1F6", >> "RCID": null, >> "RID": null, >> "ECID": "8ec006a7-30e9-4fac-be7f-716f42d3cbc8-0000001c", >> "ejbMethodName": null, >> "ejbName": null, >> "componentName": null, >> "applicationName": null, >> "subsystem": "EJB" >> } >> >>
>> >>
>> jdk.PSHeapSummary >> >> >> { >> "eventType": "jdk.PSHeapSummary", >> "attributes": { >> "(endTime)": 1384767779307774408, >> "gcId": 4, >> "when": "After GC", >> "oldSpace:start": 3758096384, >> "oldSpace:committedEnd": 3937402880, >> "oldSpace:committedSize": 179306496, >> "oldSpace:reservedEnd": 4115660800, >> "oldSpace:reservedSize": 357564416, >> "oldObjectSpace:start": 3758096384, >> "oldObjectSpace:end": 3937402880, >> "oldObjectSpace:used": 50007536, >> "oldObjectSpace:size": 179306496, >> "youngSpace:start": 4115660800, >> "youngSpace:committedEnd": 4294967296, >> "youngSpace:committedSize": 179306496, >> "youngSpace:reservedEnd": 4294967296, >> "youngSpace:reservedSize": 179306496, >> "edenSpace:start": 4115660800, >> "edenSpace:end": 4272947200, >> "edenSpace:used": 0, >> "edenSpace:size": 157286400, >> "fromSpace:start": 4272947200, >> "fromSpace:end": 4283957248, >> "fromSpace:used": 10977416, >> "fromSpace:size": 11010048, >> "toSpace:start": 4283957248, >> "toSpace:end": 4294967296, >> "toSpace:used": 0, >> "toSpace:size": 11010048 >> } >> >>
>> >>
>> jdk.NetworkUtilization >> >> >> { >> "eventType": "jdk.NetworkUtilization", >> "attributes": { >> "startTime": 1541771978642206341, >> "networkInterface": "Hyper-V Virtual Ethernet Adapter #15", >> "readRate": 3349, >> "writeRate": 461 >> } >> } > > Alex Ciminian has updated the pull request incrementally with one additional commit since the last revision: > > Fix modifier order in StructuredWriter methods Hi @cimi! You can now /integrate. ------------- PR: https://git.openjdk.java.net/jmc/pull/279 From github.com+348973+cimi at openjdk.java.net Thu Sep 9 13:21:02 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Thu, 9 Sep 2021 13:21:02 GMT Subject: Integrated: 7393: Add vanilla Java JSON serializer for IItemCollections In-Reply-To: References: Message-ID: <_DgMTcjUKDQzfidp3nNwBCUfCy-xAdZ9F4Mt6wHo-y0=.b95efa04-ec72-447f-abd6-3b7030e193f0@github.com> On Wed, 21 Jul 2021 16:42:41 GMT, Alex Ciminian wrote: > ## What is this? > > This PR adds a JSON serialiser for IItemCollections, with no other library dependencies. This implementation was originally done in #225 with the goal of providing JSON data directly to the browser over a WebSocket. > > We could use this as a generic representation of events to drive all visualisations we display in JMC since all structures (tree, graph etc) can be constructed from this base format. This would ensure a uniform interface for all visualisations (they could all expect event JSON data). > > ## Serialized event structure > > The serialized recording currently looks like this: > > > { > "events": [{ > "eventType": "", > "attributes": { > "": "", > "": "" > } > }] > } > > > We've previously discussed having a `metadata` section in the JSON file in order to avoid repeating the attribute names - this is not implemented yet and I'd like to understand better how we want it to look like. It would be good to have a consistent representation of the event types and attributes across recordings so i.e. we don't encode them to different symbols and then have the same item represented in different ways. Since the encoding table will be shipped with the serialised items, in practice they can be decoded to the same thing but I'm not sure the benefit is worth the complexity. The only benefit I see for this is having a smaller document size, but we can probably get better compression if we just use zip. > > ## Testing and benchmarking > > This PR currently has no tests because I wasn't sure how we want to run them here and what test data I can use. [This project, jmc-json-benchmarks](https://github.com/cimi/jmc-json-benchmarks), has the same code with tests and also has logic to benchmark different JSON serialisation implementations using JMH. While doing the JMH analysis, we found that FastJSON is significantly faster compared to this ad-hoc implementation, but for simplicity we can start with this implementation and replace later if performance becomes an issue. > > You can see the benchmark results here: https://jmh.morethan.io/?source=https://raw.githubusercontent.com/cimi/jmc-json-benchmarks/master/all-results.json > > ## Examples of serialised events > > These examples were taken from the test cases used to validate the implementation, you can see the full test output here: > > * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/latency_before.json > * https://github.com/cimi/jmc-json-benchmarks/blob/master/src/test/resources/wldf.json > > (The number of events serialised from the recording was truncated). > >
> EJB_Pool_Manager_Pre_Invoke > > > { > "eventType": "http://www.oracle.com/wls/flightrecorder/medium/wls/EJB/EJB_Pool_Manager_Pre_Invoke", > "attributes": { > "(endTime)": 1384767793251009019, > "eventThread": "[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'", > "stackTrace": { > "frames": [{ > "name": "weblogic.diagnostics.instrumentation.gathering.FlightRecorderEventHelper#recordStatelessEvent(Lweblogic/diagnostics/instrumentation/DiagnosticMonitor;Lweblogic/diagnostics/instrumentation/JoinPoint;)V", > "line": 92, > "type": "INTERPRETED" > }, { > "name": "weblogic.diagnostics.instrumentation.action.FlightRecorderStatelessAction#process(Lweblogic/diagnostics/instrumentation/JoinPoint;)V", > "line": 51, > "type": "INTERPRETED" > }, [... many others ...], { > "name": "weblogic.work.ExecuteThread#run()V", > "line": 248, > "type": "INTERPRETED" > }] > }, > "userID": "", > "returnValue": "", > "methodName": "preInvoke", > "className": "weblogic.ejb.container.manager.StatelessManager", > "transactionID": "BEA1-000217F1E993CDB6E1F6", > "RCID": null, > "RID": null, > "ECID": "8ec006a7-30e9-4fac-be7f-716f42d3cbc8-0000001c", > "ejbMethodName": null, > "ejbName": null, > "componentName": null, > "applicationName": null, > "subsystem": "EJB" > } > >
> >
> jdk.PSHeapSummary > > > { > "eventType": "jdk.PSHeapSummary", > "attributes": { > "(endTime)": 1384767779307774408, > "gcId": 4, > "when": "After GC", > "oldSpace:start": 3758096384, > "oldSpace:committedEnd": 3937402880, > "oldSpace:committedSize": 179306496, > "oldSpace:reservedEnd": 4115660800, > "oldSpace:reservedSize": 357564416, > "oldObjectSpace:start": 3758096384, > "oldObjectSpace:end": 3937402880, > "oldObjectSpace:used": 50007536, > "oldObjectSpace:size": 179306496, > "youngSpace:start": 4115660800, > "youngSpace:committedEnd": 4294967296, > "youngSpace:committedSize": 179306496, > "youngSpace:reservedEnd": 4294967296, > "youngSpace:reservedSize": 179306496, > "edenSpace:start": 4115660800, > "edenSpace:end": 4272947200, > "edenSpace:used": 0, > "edenSpace:size": 157286400, > "fromSpace:start": 4272947200, > "fromSpace:end": 4283957248, > "fromSpace:used": 10977416, > "fromSpace:size": 11010048, > "toSpace:start": 4283957248, > "toSpace:end": 4294967296, > "toSpace:used": 0, > "toSpace:size": 11010048 > } > >
> >
> jdk.NetworkUtilization > > > { > "eventType": "jdk.NetworkUtilization", > "attributes": { > "startTime": 1541771978642206341, > "networkInterface": "Hyper-V Virtual Ethernet Adapter #15", > "readRate": 3349, > "writeRate": 461 > } > } This pull request has now been integrated. Changeset: 2844db9f Author: Alex Ciminian Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/2844db9fab2164b1c6b675466bbd5a5e805e9560 Stats: 6704 lines in 5 files changed: 6704 ins; 0 del; 0 mod 7393: Add vanilla Java JSON serializer for IItemCollections Reviewed-by: hirt, jpbempel ------------- PR: https://git.openjdk.java.net/jmc/pull/279 From jbachorik at openjdk.java.net Thu Sep 9 13:59:03 2021 From: jbachorik at openjdk.java.net (Jaroslav Bachorik) Date: Thu, 9 Sep 2021 13:59:03 GMT Subject: Integrated: 7338: Add parser support for frame types generated by async-profiler In-Reply-To: References: Message-ID: On Fri, 9 Jul 2021 09:50:52 GMT, Jaroslav Bachorik wrote: > Async Profiler (https://github.com/jvm-profiling-tools/async-profiler) is able to generate JFR recordings with CPU and allocation sample events spanning full-stack (from Java to OS/kernel). > It is adding three new frame types for this reason: > > - Native (C) > - C++ > - Kernel > > > Currently, the JMC parser will process all those frame types as 'UNKNOWN'. Although it is not breaking the rendering it would be nice to be able to get more info about the actual frame type. This pull request has now been integrated. Changeset: 341f3d54 Author: Jaroslav Bachorik Committer: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/341f3d54666774874d1ec5ba7b708129000de661 Stats: 23 lines in 2 files changed: 21 ins; 0 del; 2 mod 7338: Add parser support for frame types generated by async-profiler Reviewed-by: hirt ------------- PR: https://git.openjdk.java.net/jmc/pull/274 From hirt at openjdk.java.net Thu Sep 9 14:02:08 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 9 Sep 2021 14:02:08 GMT Subject: RFR: 7231: JMC createReport for JMC8 Automated Analysis fails to evaluate several rules In-Reply-To: References: <7A74lcRU7j2A9qas1BwWturLRNFuLIcUs5fAhv5IoTY=.8e9f35d2-07ec-4347-b5ee-c2c9a2926cce@github.com> Message-ID: On Tue, 31 Aug 2021 00:02:47 GMT, Henrik Dafg?rd wrote: >> This PR addresses the NullPointerException issue in core module for the following rules: >> >> 1. GCs Caused by System.gc() >> 2. GCs Caused by Heap Inspection >> 3. GC Stall >> 4. String Deduplication >> 5. GCs Caused by GC Locker > > The ResultProvider should always be available for a IRule imlementation. If it isn't then that's a bug that we need to fix instead. I'd rather fix that at the source than adding null checks all over the code. @Gunde - is there an issue open for this? ------------- PR: https://git.openjdk.java.net/jmc/pull/302 From hirt at openjdk.java.net Thu Sep 9 19:38:08 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 9 Sep 2021 19:38:08 GMT Subject: RFR: 7378: Update platform to 2021-06 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 22:08:14 GMT, Marcus Hirt wrote: > ...and removing old ones. So. After not being able to figure out what is wrong, I nuked my local repo, my .m2 cache etc. And, yep, the UI tests work now. :'( ------------- PR: https://git.openjdk.java.net/jmc/pull/301 From hirt at openjdk.java.net Thu Sep 9 19:38:08 2021 From: hirt at openjdk.java.net (Marcus Hirt) Date: Thu, 9 Sep 2021 19:38:08 GMT Subject: Integrated: 7378: Update platform to 2021-06 In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 22:08:14 GMT, Marcus Hirt wrote: > ...and removing old ones. This pull request has now been integrated. Changeset: d05f377b Author: Marcus Hirt URL: https://git.openjdk.java.net/jmc/commit/d05f377bdc5e4028db618e0d5f79c052136e1578 Stats: 365 lines in 34 files changed: 60 ins; 242 del; 63 mod 7378: Update platform to 2021-06 Reviewed-by: ghb ------------- PR: https://git.openjdk.java.net/jmc/pull/301 From github.com+348973+cimi at openjdk.java.net Mon Sep 13 10:33:05 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Mon, 13 Sep 2021 10:33:05 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates Message-ID: This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. ### Dependency management I've struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. [ERROR] [ERROR] Chain 1: [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] [ERROR] require: (osgi.wiring.bundle=javax.servlet) [ERROR] | [ERROR] provide: osgi.wiring.bundle: javax.servlet [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] [ERROR] [ERROR] Chain 2: [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) [ERROR] | [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) [ERROR] | [ERROR] export: osgi.wiring.package: javax.servlet [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? I don't understand why this is happening or how to fix it. org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" org.openjdk.jmc.flightrecorder.ui [445] Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" ------------- Commit messages: - Require specific jetty bundle version to avoid conflict in ui tests - Remove explicit dependency on javax.servlet-api - Refactor WebsocketServer and embed inside JfrEditor - Add proof of concept websocket server implementation - Add listener in JfrEditor for websocket configuration changes - Add dependency on javax.websocket and eclipse jetty in flightrecorder.ui - Add setting to enable websocket server in preferences Changes: https://git.openjdk.java.net/jmc/pull/306/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7198 Stats: 379 lines in 18 files changed: 324 ins; 0 del; 55 mod Patch: https://git.openjdk.java.net/jmc/pull/306.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/306/head:pull/306 PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+803621+bric3 at openjdk.java.net Tue Sep 14 12:28:08 2021 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Tue, 14 Sep 2021 12:28:08 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates In-Reply-To: References: Message-ID: On Thu, 9 Sep 2021 16:32:58 GMT, Alex Ciminian wrote: > This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. > > ### Dependency management > > I've struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: > > > org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. > [ERROR] > [ERROR] Chain 1: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=javax.servlet) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle: javax.servlet > [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] > [ERROR] > [ERROR] Chain 2: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" > [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] > [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) > [ERROR] | > [ERROR] export: osgi.wiring.package: javax.servlet > [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] > > > This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. > > I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? I don't understand why this is happening or how to fix it. > > > org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] > Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui > -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" > org.openjdk.jmc.flightrecorder.ui [445] > Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" Nice stepping stone toward flexible UIs. There's still some println here and there ;) Stopping the websocket server is not yet implemented. application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrEditor.java line 134: > 132: websocketServerEnabledListener = e -> { > 133: if (e.getProperty().equals(PreferenceKeys.PROPERTY_ENABLE_WEBSOCKET_SERVER)) { > 134: if ((Boolean) e.getNewValue()) { For readability purpose maybe this code could benefit from an explicit equality check application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/websocket/WebsocketServer.java line 23: > 21: > 22: public class WebsocketServer { > 23: private static int PORT = 8029; I think the port should be configurable. application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/websocket/WebsocketServer.java line 37: > 35: Server server = new Server(); > 36: ServerConnector connector = new ServerConnector(server); > 37: connector.setPort(PORT); I'm not quite sure how this feature will be used, but can it make sense to only bind to locahost ? releng/third-party/pom.xml line 50: > 48: 1.6.5 > 49: 1.1 > 50: 9.4.43.v20210629 I have seen in the PR description this codes needs to stick with 9.4.43?. But I noticed the coordinate of the artefacts may have changed after version 9 (group:`org.eclipse.jetty.websocket`, artefact: `wesocket-server` -> `websocket-jetty-server`). I haven't yet checked the dependencies in the POM, maybe that helps. By the way there's a more recent version of [jetty 11.0.6](https://search.maven.org/artifact/org.eclipse.jetty.websocket/websocket-jetty-server/11.0.6/jar). ------------- PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+803621+bric3 at openjdk.java.net Tue Sep 14 12:43:06 2021 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Tue, 14 Sep 2021 12:43:06 GMT Subject: RFR: 7308: Move non-Eclipse dependant classes from org.openjdk.jmc.ui.common to org.openjdk.jmc.common In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 21:30:22 GMT, Alex Macdonald wrote: > This PR addresses JMC-7308 [[0]](https://bugs.openjdk.java.net/browse/JMC-7308), in which it would be helpful to have some of the classes currently in jmc.ui.common shipped in core. > > There are a number of classes currently in jmc.ui.common that would be a great asset to the core distribution (and the third-party applications that consume jmc-core), and these classes could live in jmc.common. > > It isn't as straightforward as moving all of the packages to core, as there are still classes in these jmc.ui.common packages that have dependencies on Eclipse or rjmx. Having said that, the ones listed below can be moved without much difficulty: > > - org.openjdk.jmc.ui.common.action (3) > Executable, IActionProvider, IUserAction > > - org.openjdk.jmc.ui.common.jvm (5) > Connectable, JVMArch, JVMCommandLineToolkit, JVMDescriptor, JVMType > > - org.openjdk.jmc.ui.common.resource (2) > IImageResource, Resource > > - org.openjdk.jmc.ui.common.security (10) > ActionNotGrantedException, CredentialsNotAvailableException, FailedToSaveException, ICredentials, InMemoryCredentials, ISecurityManager, PersistentCredentials, SecurlyStoredByteArray, SecurityException, SecurityManagerFactory > > - org.opendjk.jmc.ui.common.tree (3) > IArray, IChild, IParent > > - org.openjdk.jmc.ui.common.util (4) > Environment, Filename, ICopyable, IObservable > > - org.openjdk.jmc.ui.common.xydata (5) > DataSeries, DefautlTimestampedData, DefaultXYData, ITimeStampedData, IXYData > > [0] https://bugs.openjdk.java.net/browse/JMC-7308 Marked as reviewed by bric3 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jmc/pull/300 From github.com+803621+bric3 at openjdk.java.net Tue Sep 14 12:48:25 2021 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Tue, 14 Sep 2021 12:48:25 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 21:30:09 GMT, Alex Macdonald wrote: > This PR addresses JMC-7307 [[0]](https://bugs.openjdk.java.net/browse/JMC-7307), in which it would be helpful to have `flightrecorder.configuration` distributed in jmc core. > > `flightrecorder.configuration` itself is a pretty straightforward movement of code, as it doesn't have any dependencies. Having said that, there are some flightrecorder-configuration-related classes in `controlpanel.ui` which would be nice to have in core as well, and would probably do well in `flightrecorder.configuration`. This includes VolatileStorageDelegate, and the 12 classes in `configuration.model.xml`. The `controlpanel.ui.configuration` unit tests can also come over to core, because they only tested the model xml code anyways. > > So in total, we're looking at `flightrecorder.configuration` and the former `controlpanel.ui.configuration` test coming over to core, and the following classes: > - org.openjdk.jmc.flightrecorder.configuration.model.VolatileStorageDelegate > - org.openjdk.jmc.flightrecorder.configuration.model.xml.IXMLValidator > - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCGrammar > - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCXMLValidator > - org.openjdk.jmc.flightrecorder.configuration.model.xml.PrettyPrinter > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttribute > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttributeInstance > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLModel > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNode > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNodeType > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTag > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTagInstance > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLValidationResult > > [0] https://bugs.openjdk.java.net/browse/JMC-7307 Marked as reviewed by bric3 at github.com (no known OpenJDK username). core/org.openjdk.jmc.flightrecorder.configuration/src/main/java/org/openjdk/jmc/flightrecorder/configuration/model/xml/JFCXMLValidator.java line 61: > 59: > 60: private static final Logger LOGGER = Logger.getLogger("org.openjdk.jmc.flightrecorder.configuration"); > 61: Is it intended to trim the end of the package (`.model.xml`) ? ------------- PR: https://git.openjdk.java.net/jmc/pull/299 From github.com+348973+cimi at openjdk.java.net Tue Sep 14 12:50:22 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Tue, 14 Sep 2021 12:50:22 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 12:14:09 GMT, Brice Dutheil wrote: >> This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. >> >> ### Dependency management >> >> I've struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: >> >> >> org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. >> [ERROR] >> [ERROR] Chain 1: >> [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] >> [ERROR] require: (osgi.wiring.bundle=javax.servlet) >> [ERROR] | >> [ERROR] provide: osgi.wiring.bundle: javax.servlet >> [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] >> [ERROR] >> [ERROR] Chain 2: >> [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] >> [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) >> [ERROR] | >> [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" >> [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] >> [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) >> [ERROR] | >> [ERROR] export: osgi.wiring.package: javax.servlet >> [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] >> >> >> This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. >> >> I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? I don't understand why this is happening or how to fix it. >> >> >> org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] >> Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui >> -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" >> org.openjdk.jmc.flightrecorder.ui [445] >> Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" > > releng/third-party/pom.xml line 50: > >> 48: 1.6.5 >> 49: 1.1 >> 50: 9.4.43.v20210629 > > I have seen in the PR description this codes needs to stick with 9.4.43?. But I noticed the coordinate of the artefacts may have changed after version 9 (group:`org.eclipse.jetty.websocket`, artefact: `wesocket-server` -> `websocket-jetty-server`). I haven't yet checked the dependencies in the POM, maybe that helps. > > By the way there's a more recent version of [jetty 11.0.6](https://search.maven.org/artifact/org.eclipse.jetty.websocket/websocket-jetty-server/11.0.6/jar). Interesting, thanks for pointing this out! I picked 9.4.43 because it was the latest version I saw here https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server I didn't notice the rename for later versions. ?? Maybe I can get rid of the dependency issues if I just use `10.0.5` which is already required by _something_ (I don't know what) in the uitests. ------------- PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+348973+cimi at openjdk.java.net Tue Sep 14 14:04:07 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Tue, 14 Sep 2021 14:04:07 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 12:47:29 GMT, Alex Ciminian wrote: >> releng/third-party/pom.xml line 50: >> >>> 48: 1.6.5 >>> 49: 1.1 >>> 50: 9.4.43.v20210629 >> >> I have seen in the PR description this codes needs to stick with 9.4.43?. But I noticed the coordinate of the artefacts may have changed after version 9 (group:`org.eclipse.jetty.websocket`, artefact: `wesocket-server` -> `websocket-jetty-server`). I haven't yet checked the dependencies in the POM, maybe that helps. >> >> By the way there's a more recent version of [jetty 11.0.6](https://search.maven.org/artifact/org.eclipse.jetty.websocket/websocket-jetty-server/11.0.6/jar). > > Interesting, thanks for pointing this out! > > I picked 9.4.43 because it was the latest version I saw here https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server I didn't notice the rename for later versions. ?? > > Maybe I can get rid of the dependency issues if I just use `10.0.5` which is already required by _something_ (I don't know what) in the uitests. ?? ?? I've just tried using 10.0.5 and I get this error: Caused by: org.osgi.framework.BundleException: Bundle org.openjdk.jmc.console.agent cannot be resolved:org.openjdk.jmc.console.agent [130] Unresolved requirement: Require-Bundle: org.openjdk.jmc.flightrecorder.ui -> Bundle-SymbolicName: org.openjdk.jmc.flightrecorder.ui; bundle-version="8.2.0.qualifier"; singleton:="true" org.openjdk.jmc.flightrecorder.ui [132] Unresolved requirement: Require-Bundle: org.eclipse.jetty.websocket-api -> Bundle-SymbolicName: org.eclipse.jetty.websocket-api; bundle-version="1.1.2" org.eclipse.jetty.websocket-api [93] Unresolved requirement: Require-Capability: osgi.extender; filter:="(osgi.extender=osgi.serviceloader.processor)" It seems this needs [SPI Fly](https://aries.apache.org/documentation/modules/spi-fly.html) now... ------------- PR: https://git.openjdk.java.net/jmc/pull/306 From aptmac at openjdk.java.net Tue Sep 14 14:33:12 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Tue, 14 Sep 2021 14:33:12 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 12:44:31 GMT, Brice Dutheil wrote: >> This PR addresses JMC-7307 [[0]](https://bugs.openjdk.java.net/browse/JMC-7307), in which it would be helpful to have `flightrecorder.configuration` distributed in jmc core. >> >> `flightrecorder.configuration` itself is a pretty straightforward movement of code, as it doesn't have any dependencies. Having said that, there are some flightrecorder-configuration-related classes in `controlpanel.ui` which would be nice to have in core as well, and would probably do well in `flightrecorder.configuration`. This includes VolatileStorageDelegate, and the 12 classes in `configuration.model.xml`. The `controlpanel.ui.configuration` unit tests can also come over to core, because they only tested the model xml code anyways. >> >> So in total, we're looking at `flightrecorder.configuration` and the former `controlpanel.ui.configuration` test coming over to core, and the following classes: >> - org.openjdk.jmc.flightrecorder.configuration.model.VolatileStorageDelegate >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.IXMLValidator >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCGrammar >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCXMLValidator >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.PrettyPrinter >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttribute >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttributeInstance >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLModel >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNode >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNodeType >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTag >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTagInstance >> - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLValidationResult >> >> [0] https://bugs.openjdk.java.net/browse/JMC-7307 > > core/org.openjdk.jmc.flightrecorder.configuration/src/main/java/org/openjdk/jmc/flightrecorder/configuration/model/xml/JFCXMLValidator.java line 61: > >> 59: >> 60: private static final Logger LOGGER = Logger.getLogger("org.openjdk.jmc.flightrecorder.configuration"); >> 61: > > Is it intended to trim the end of the package (`.model.xml`) ? Nice catch, no that was an accident, thanks for the review ------------- PR: https://git.openjdk.java.net/jmc/pull/299 From github.com+348973+cimi at openjdk.java.net Tue Sep 14 18:11:35 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Tue, 14 Sep 2021 18:11:35 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v2] In-Reply-To: References: Message-ID: > This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. > > ### Dependency management > > I've struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: > > > org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. > [ERROR] > [ERROR] Chain 1: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=javax.servlet) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle: javax.servlet > [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] > [ERROR] > [ERROR] Chain 2: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" > [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] > [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) > [ERROR] | > [ERROR] export: osgi.wiring.package: javax.servlet > [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] > > > This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. > > I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? I don't understand why this is happening or how to fix it. > > > org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] > Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui > -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" > org.openjdk.jmc.flightrecorder.ui [445] > Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" Alex Ciminian has updated the pull request incrementally with one additional commit since the last revision: Upgrade jetty to 10.0.5 ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/306/files - new: https://git.openjdk.java.net/jmc/pull/306/files/8f3d3cee..20779699 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=00-01 Stats: 35 lines in 5 files changed: 18 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jmc/pull/306.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/306/head:pull/306 PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+348973+cimi at openjdk.java.net Tue Sep 14 18:46:02 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Tue, 14 Sep 2021 18:46:02 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v3] In-Reply-To: References: Message-ID: <7Z3LPWLq-w2QX_RobZktc8fHFhYyCMI9oddfnhdoEDo=.601a7555-4d87-494d-9262-684e7ffd5b43@github.com> > This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. > > ### Dependency management > > I've struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: > > > org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. > [ERROR] > [ERROR] Chain 1: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=javax.servlet) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle: javax.servlet > [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] > [ERROR] > [ERROR] Chain 2: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" > [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] > [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) > [ERROR] | > [ERROR] export: osgi.wiring.package: javax.servlet > [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] > > > This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. > > I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? I don't understand why this is happening or how to fix it. > > > org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] > Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui > -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" > org.openjdk.jmc.flightrecorder.ui [445] > Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" Alex Ciminian has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: - Replace prints in websocket server with logger - Upgrade jetty to 10.0.5 ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/306/files - new: https://git.openjdk.java.net/jmc/pull/306/files/20779699..16c3ca79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=01-02 Stats: 29 lines in 1 file changed: 7 ins; 8 del; 14 mod Patch: https://git.openjdk.java.net/jmc/pull/306.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/306/head:pull/306 PR: https://git.openjdk.java.net/jmc/pull/306 From aptmac at openjdk.java.net Tue Sep 14 21:23:44 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Tue, 14 Sep 2021 21:23:44 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core [v2] In-Reply-To: References: Message-ID: > This PR addresses JMC-7307 [[0]](https://bugs.openjdk.java.net/browse/JMC-7307), in which it would be helpful to have `flightrecorder.configuration` distributed in jmc core. > > `flightrecorder.configuration` itself is a pretty straightforward movement of code, as it doesn't have any dependencies. Having said that, there are some flightrecorder-configuration-related classes in `controlpanel.ui` which would be nice to have in core as well, and would probably do well in `flightrecorder.configuration`. This includes VolatileStorageDelegate, and the 12 classes in `configuration.model.xml`. The `controlpanel.ui.configuration` unit tests can also come over to core, because they only tested the model xml code anyways. > > So in total, we're looking at `flightrecorder.configuration` and the former `controlpanel.ui.configuration` test coming over to core, and the following classes: > - org.openjdk.jmc.flightrecorder.configuration.model.VolatileStorageDelegate > - org.openjdk.jmc.flightrecorder.configuration.model.xml.IXMLValidator > - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCGrammar > - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCXMLValidator > - org.openjdk.jmc.flightrecorder.configuration.model.xml.PrettyPrinter > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttribute > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttributeInstance > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLModel > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNode > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNodeType > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTag > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTagInstance > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLValidationResult > > [0] https://bugs.openjdk.java.net/browse/JMC-7307 Alex Macdonald has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - fix package name in JFCXMLValidator logger - re-order flightrecorder.configuration.test in test pom - update license headers - migrate VolatileStorageDelegate to flightrecorder.configuration.model - revert .classpath files to their original from application - minor cleanup - move configuration.model.xml test from application to core; remove controlpanel.ui.configuration.test The controlpanel.ui.configuration only had the XML test, which is now located in flightrecorder.configuration.test in core. Currently all tests in both core and application will pass. - move flightrecorder.configuration coverage from application to core - temporarily silence test modules that are moved, will cleanup after - migrate controlpanel.ui.configuration.model.xml to core - ... and 1 more: https://git.openjdk.java.net/jmc/compare/d05f377b...c6b5c22c ------------- Changes: https://git.openjdk.java.net/jmc/pull/299/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=299&range=01 Stats: 1004 lines in 99 files changed: 373 ins; 475 del; 156 mod Patch: https://git.openjdk.java.net/jmc/pull/299.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/299/head:pull/299 PR: https://git.openjdk.java.net/jmc/pull/299 From aptmac at openjdk.java.net Tue Sep 14 21:24:16 2021 From: aptmac at openjdk.java.net (Alex Macdonald) Date: Tue, 14 Sep 2021 21:24:16 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core In-Reply-To: References: Message-ID: On Mon, 9 Aug 2021 21:30:09 GMT, Alex Macdonald wrote: > This PR addresses JMC-7307 [[0]](https://bugs.openjdk.java.net/browse/JMC-7307), in which it would be helpful to have `flightrecorder.configuration` distributed in jmc core. > > `flightrecorder.configuration` itself is a pretty straightforward movement of code, as it doesn't have any dependencies. Having said that, there are some flightrecorder-configuration-related classes in `controlpanel.ui` which would be nice to have in core as well, and would probably do well in `flightrecorder.configuration`. This includes VolatileStorageDelegate, and the 12 classes in `configuration.model.xml`. The `controlpanel.ui.configuration` unit tests can also come over to core, because they only tested the model xml code anyways. > > So in total, we're looking at `flightrecorder.configuration` and the former `controlpanel.ui.configuration` test coming over to core, and the following classes: > - org.openjdk.jmc.flightrecorder.configuration.model.VolatileStorageDelegate > - org.openjdk.jmc.flightrecorder.configuration.model.xml.IXMLValidator > - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCGrammar > - org.openjdk.jmc.flightrecorder.configuration.model.xml.JFCXMLValidator > - org.openjdk.jmc.flightrecorder.configuration.model.xml.PrettyPrinter > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttribute > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLAttributeInstance > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLModel > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNode > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLNodeType > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTag > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLTagInstance > - org.openjdk.jmc.flightrecorder.configuration.model.xml.XMLValidationResult > > [0] https://bugs.openjdk.java.net/browse/JMC-7307 Rebased & addressed the misnaming of the package in the JFCXMLValidator logger. Thanks for the reviews! This PR introduces some large changes for core, and will be targeting jmc 9. ------------- PR: https://git.openjdk.java.net/jmc/pull/299 From github.com+803621+bric3 at openjdk.java.net Wed Sep 15 07:18:48 2021 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Wed, 15 Sep 2021 07:18:48 GMT Subject: RFR: 7307: Move org.openjdk.jmc.flightrecorder.configuration bundle from application to core [v2] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 14:30:20 GMT, Alex Macdonald wrote: >> core/org.openjdk.jmc.flightrecorder.configuration/src/main/java/org/openjdk/jmc/flightrecorder/configuration/model/xml/JFCXMLValidator.java line 61: >> >>> 59: >>> 60: private static final Logger LOGGER = Logger.getLogger("org.openjdk.jmc.flightrecorder.configuration"); >>> 61: >> >> Is it intended to trim the end of the package (`.model.xml`) ? > > Nice catch, no that was an accident, thanks for the review You're welcome :) ------------- PR: https://git.openjdk.java.net/jmc/pull/299 From github.com+803621+bric3 at openjdk.java.net Wed Sep 15 07:25:51 2021 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Wed, 15 Sep 2021 07:25:51 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v3] In-Reply-To: <7Z3LPWLq-w2QX_RobZktc8fHFhYyCMI9oddfnhdoEDo=.601a7555-4d87-494d-9262-684e7ffd5b43@github.com> References: <7Z3LPWLq-w2QX_RobZktc8fHFhYyCMI9oddfnhdoEDo=.601a7555-4d87-494d-9262-684e7ffd5b43@github.com> Message-ID: <8Zo9pfqTghjVwCVeuwHW1obhPwD1mO30r8oR5z73VQo=.131d1771-d63d-498f-a0bb-4a4bb5e6c405@github.com> On Tue, 14 Sep 2021 18:46:02 GMT, Alex Ciminian wrote: >> This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. >> >> ### Dependency management >> >> I've struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: >> >> >> org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. >> [ERROR] >> [ERROR] Chain 1: >> [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] >> [ERROR] require: (osgi.wiring.bundle=javax.servlet) >> [ERROR] | >> [ERROR] provide: osgi.wiring.bundle: javax.servlet >> [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] >> [ERROR] >> [ERROR] Chain 2: >> [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] >> [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) >> [ERROR] | >> [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" >> [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] >> [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) >> [ERROR] | >> [ERROR] export: osgi.wiring.package: javax.servlet >> [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] >> >> >> This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. >> >> I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? I don't understand why this is happening or how to fix it. >> >> >> org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] >> Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui >> -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" >> org.openjdk.jmc.flightrecorder.ui [445] >> Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" > > Alex Ciminian has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision: > > - Replace prints in websocket server with logger > - Upgrade jetty to 10.0.5 releng/platform-definitions/platform-definition-2021-03/platform-definition-2021-03.target line 51: > 49: > 50: > 51: It seems there's still references to jetty 9 in older platform definition. I'm not familiar with eclipse based applications, but should those target be removed once the platform is upgraded to a more recent version ? releng/platform-definitions/platform-definition-2021-06/platform-definition-2021-06.target line 55: > 53: > 54: > 55: .servlet-api_4.0.6.jar I think this shouldn't be there ;) ------------- PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+803621+bric3 at openjdk.java.net Wed Sep 15 07:25:51 2021 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Wed, 15 Sep 2021 07:25:51 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v3] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 14:00:54 GMT, Alex Ciminian wrote: >> Interesting, thanks for pointing this out! >> >> I picked 9.4.43 because it was the latest version I saw here https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server I didn't notice the rename for later versions. ?? >> >> Maybe I can get rid of the dependency issues if I just use `10.0.5` which is already required by _something_ (I don't know what) in the uitests. > > ?? ?? I've just tried using 10.0.5 and I get this error: > > > Caused by: org.osgi.framework.BundleException: Bundle org.openjdk.jmc.console.agent cannot be resolved:org.openjdk.jmc.console.agent [130] > Unresolved requirement: Require-Bundle: org.openjdk.jmc.flightrecorder.ui > -> Bundle-SymbolicName: org.openjdk.jmc.flightrecorder.ui; bundle-version="8.2.0.qualifier"; singleton:="true" > org.openjdk.jmc.flightrecorder.ui [132] > Unresolved requirement: Require-Bundle: org.eclipse.jetty.websocket-api > -> Bundle-SymbolicName: org.eclipse.jetty.websocket-api; bundle-version="1.1.2" > org.eclipse.jetty.websocket-api [93] > Unresolved requirement: Require-Capability: osgi.extender; filter:="(osgi.extender=osgi.serviceloader.processor)" > > > It seems this needs [SPI Fly](https://aries.apache.org/documentation/modules/spi-fly.html) now... So it seems you finally go this working :) ------------- PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+348973+cimi at openjdk.java.net Wed Sep 15 11:30:35 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Wed, 15 Sep 2021 11:30:35 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v4] In-Reply-To: References: Message-ID: > This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. > > ### Dependency management > > I've struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: > > > org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. > [ERROR] > [ERROR] Chain 1: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=javax.servlet) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle: javax.servlet > [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] > [ERROR] > [ERROR] Chain 2: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" > [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] > [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) > [ERROR] | > [ERROR] export: osgi.wiring.package: javax.servlet > [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] > > > This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. > > I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? I don't understand why this is happening or how to fix it. > > > org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] > Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui > -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" > org.openjdk.jmc.flightrecorder.ui [445] > Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" Alex Ciminian has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains four new commits since the last revision: - Make websocket server port configurable - Make port a constructor argument for WebsocketServer - Replace prints in websocket server with logger - Upgrade jetty to 10.0.5 and add spifly ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/306/files - new: https://git.openjdk.java.net/jmc/pull/306/files/16c3ca79..15f9f810 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=02-03 Stats: 164 lines in 14 files changed: 107 ins; 27 del; 30 mod Patch: https://git.openjdk.java.net/jmc/pull/306.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/306/head:pull/306 PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+348973+cimi at openjdk.java.net Wed Sep 15 11:55:32 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Wed, 15 Sep 2021 11:55:32 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v5] In-Reply-To: References: Message-ID: <9kMYn-fvsKrfR1VgXTaB6FEA4Nzg4YK95_BFUfvp4-Q=.4469da5c-b59c-4414-a43b-8bea68aa82df@github.com> > This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. > > ### Dependency management > > I've struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: > > > org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. > [ERROR] > [ERROR] Chain 1: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=javax.servlet) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle: javax.servlet > [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] > [ERROR] > [ERROR] Chain 2: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" > [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] > [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) > [ERROR] | > [ERROR] export: osgi.wiring.package: javax.servlet > [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] > > > This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. > > I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? I don't understand why this is happening or how to fix it. > > > org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] > Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui > -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" > org.openjdk.jmc.flightrecorder.ui [445] > Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" Alex Ciminian has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Make websocket server port configurable ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/306/files - new: https://git.openjdk.java.net/jmc/pull/306/files/15f9f810..eb04ded7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=03-04 Stats: 7 lines in 3 files changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jmc/pull/306.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/306/head:pull/306 PR: https://git.openjdk.java.net/jmc/pull/306 From jpbempel at openjdk.java.net Wed Sep 15 21:01:23 2021 From: jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Wed, 15 Sep 2021 21:01:23 GMT Subject: RFR: 7336: Add support for new JFR event systemGC Message-ID: `SystemGC` event brings stacktrace when a `System.gc()` is triggered We can then correlate with GarbageCollection event with "System.gc()" cause to this new event to be able to show stacktrace in Stacktrace View/Flameview Screenshot 2021-09-15 at 22 54 03 ------------- Commit messages: - 7336: Add support for new JFR event systemGC Changes: https://git.openjdk.java.net/jmc/pull/307/files Webrev: https://webrevs.openjdk.java.net/?repo=jmc&pr=307&range=00 Issue: https://bugs.openjdk.java.net/browse/JMC-7336 Stats: 158 lines in 4 files changed: 154 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jmc/pull/307.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/307/head:pull/307 PR: https://git.openjdk.java.net/jmc/pull/307 From jpbempel at openjdk.java.net Thu Sep 16 06:58:45 2021 From: jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Thu, 16 Sep 2021 06:58:45 GMT Subject: RFR: 7336: Add support for new JFR event systemGC [v2] In-Reply-To: References: Message-ID: > `SystemGC` event brings stacktrace when a `System.gc()` is triggered > We can then correlate with GarbageCollection event with "System.gc()" > cause to this new event to be able to show stacktrace in Stacktrace > View/Flameview > > Screenshot 2021-09-15 at 22 54 03 Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: formatting ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/307/files - new: https://git.openjdk.java.net/jmc/pull/307/files/3b0f0b3a..99a7aad9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=307&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=307&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jmc/pull/307.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/307/head:pull/307 PR: https://git.openjdk.java.net/jmc/pull/307 From github.com+348973+cimi at openjdk.java.net Thu Sep 16 21:10:12 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Thu, 16 Sep 2021 21:10:12 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v6] In-Reply-To: References: Message-ID: > This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. > > ![Screenshot 2021-09-15 at 12 08 56](https://user-images.githubusercontent.com/348973/133478041-ee436fbd-de3a-471d-955d-d0fe4cc854bf.png) > > ### Dependency management > > > Brice pointed out that there are newer versions of the Jetty websocket server available under a different artefact name - I used the same version as required in the UI tests (`10.0.5`) and this made the build succeed in both eclipse and CLI. I've had to add SPI fly since it was required by jetty, but I don't really understand what it does. > > Initially I struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: > > > org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. > [ERROR] > [ERROR] Chain 1: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=javax.servlet) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle: javax.servlet > [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] > [ERROR] > [ERROR] Chain 2: > [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] > [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) > [ERROR] | > [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" > [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] > [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) > [ERROR] | > [ERROR] export: osgi.wiring.package: javax.servlet > [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] > > > This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. > > I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? > > > org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] > Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui > -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" > org.openjdk.jmc.flightrecorder.ui [445] > Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" Alex Ciminian has updated the pull request incrementally with two additional commits since the last revision: - Add tree and graph handlers to websocket server - Revert whitespace changes in core/features.xml ------------- Changes: - all: https://git.openjdk.java.net/jmc/pull/306/files - new: https://git.openjdk.java.net/jmc/pull/306/files/eb04ded7..32d530b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jmc&pr=306&range=04-05 Stats: 89 lines in 3 files changed: 68 ins; 1 del; 20 mod Patch: https://git.openjdk.java.net/jmc/pull/306.diff Fetch: git fetch https://git.openjdk.java.net/jmc pull/306/head:pull/306 PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+348973+cimi at openjdk.java.net Thu Sep 16 21:14:48 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Thu, 16 Sep 2021 21:14:48 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v6] In-Reply-To: References: Message-ID: On Tue, 14 Sep 2021 11:40:28 GMT, Brice Dutheil wrote: >> Alex Ciminian has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add tree and graph handlers to websocket server >> - Revert whitespace changes in core/features.xml > > application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/JfrEditor.java line 134: > >> 132: websocketServerEnabledListener = e -> { >> 133: if (e.getProperty().equals(PreferenceKeys.PROPERTY_ENABLE_WEBSOCKET_SERVER)) { >> 134: if ((Boolean) e.getNewValue()) { > > For readability purpose maybe this code could benefit from an explicit equality check This is refactored, we don't use a boolean setting to see if we should enable the server. > application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/websocket/WebsocketServer.java line 23: > >> 21: >> 22: public class WebsocketServer { >> 23: private static int PORT = 8029; > > I think the port should be configurable. This is done now - instead of a checkbox to enable the server, users need to pick a port number with `0` being the default value. When `0` is selected the webserver is disabled. We had a discussion about this and @jpbempel pointed out that 0 is a valid port number that means the operating system should pick an open port. Since we don't display the port number in the UI anywhere, binding to a random port will be confusing for the user because they won't know what to connect to ?? So I think it's ok to keep `0` as the disabled value, what do you think? > application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/websocket/WebsocketServer.java line 37: > >> 35: Server server = new Server(); >> 36: ServerConnector connector = new ServerConnector(server); >> 37: connector.setPort(PORT); > > I'm not quite sure how this feature will be used, but can it make sense to only bind to locahost ? ?? Yup, definitely! This was in the plan ?? it's done now. ------------- PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+348973+cimi at openjdk.java.net Thu Sep 16 21:14:49 2021 From: github.com+348973+cimi at openjdk.java.net (Alex Ciminian) Date: Thu, 16 Sep 2021 21:14:49 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v3] In-Reply-To: <8Zo9pfqTghjVwCVeuwHW1obhPwD1mO30r8oR5z73VQo=.131d1771-d63d-498f-a0bb-4a4bb5e6c405@github.com> References: <7Z3LPWLq-w2QX_RobZktc8fHFhYyCMI9oddfnhdoEDo=.601a7555-4d87-494d-9262-684e7ffd5b43@github.com> <8Zo9pfqTghjVwCVeuwHW1obhPwD1mO30r8oR5z73VQo=.131d1771-d63d-498f-a0bb-4a4bb5e6c405@github.com> Message-ID: <1LNWOAXTKJpMhD5F1wxIYLbTU_FwWExdJ9ODNHz7wt0=.3f6f1282-df4c-4c89-a47f-067c5fa5c3c2@github.com> On Wed, 15 Sep 2021 07:22:00 GMT, Brice Dutheil wrote: >> Alex Ciminian has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. > > releng/platform-definitions/platform-definition-2021-03/platform-definition-2021-03.target line 51: > >> 49: >> 50: >> 51: > > It seems there's still references to jetty 9 in older platform definition. > > I'm not familiar with eclipse based applications, but should those target be removed once the platform is upgraded to a more recent version ? ?? Cleaned up now, I was just fiddling around with this config trying to get the dependencies to resolve properly and I was just updating the active one. > releng/platform-definitions/platform-definition-2021-06/platform-definition-2021-06.target line 55: > >> 53: >> 54: >> 55: .servlet-api_4.0.6.jar > > I think this shouldn't be there ;) Oops ?? glad it didn't complain... ------------- PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+803621+bric3 at openjdk.java.net Fri Sep 17 07:37:54 2021 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Fri, 17 Sep 2021 07:37:54 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v6] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 21:09:53 GMT, Alex Ciminian wrote: >> application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/websocket/WebsocketServer.java line 23: >> >>> 21: >>> 22: public class WebsocketServer { >>> 23: private static int PORT = 8029; >> >> I think the port should be configurable. > > This is done now - instead of a checkbox to enable the server, users need to pick a port number with `0` being the default value. When `0` is selected the webserver is disabled. > > We had a discussion about this and @jpbempel pointed out that 0 is a valid port number that means the operating system should pick an open port. Since we don't display the port number in the UI anywhere, binding to a random port will be confusing for the user because they won't know what to connect to ?? So I think it's ok to keep `0` as the disabled value, what do you think? In general I think it's ok to allow automatic port binding as long as this information is being sent back to the user. But for this use case it's not critical, so using zero to disable the server is OK for me. And if this prove to be too much misleading this can be changed without too much effort. ------------- PR: https://git.openjdk.java.net/jmc/pull/306 From github.com+803621+bric3 at openjdk.java.net Fri Sep 17 07:48:51 2021 From: github.com+803621+bric3 at openjdk.java.net (Brice Dutheil) Date: Fri, 17 Sep 2021 07:48:51 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v6] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 21:10:12 GMT, Alex Ciminian wrote: >> This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. >> >> ![Screenshot 2021-09-15 at 12 08 56](https://user-images.githubusercontent.com/348973/133478041-ee436fbd-de3a-471d-955d-d0fe4cc854bf.png) >> >> ### Dependency management >> >> >> Brice pointed out that there are newer versions of the Jetty websocket server available under a different artefact name - I used the same version as required in the UI tests (`10.0.5`) and this made the build succeed in both eclipse and CLI. I've had to add SPI fly since it was required by jetty, but I don't really understand what it does. >> >> Initially I struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: >> >> >> org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. >> [ERROR] >> [ERROR] Chain 1: >> [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] >> [ERROR] require: (osgi.wiring.bundle=javax.servlet) >> [ERROR] | >> [ERROR] provide: osgi.wiring.bundle: javax.servlet >> [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] >> [ERROR] >> [ERROR] Chain 2: >> [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] >> [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) >> [ERROR] | >> [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" >> [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] >> [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) >> [ERROR] | >> [ERROR] export: osgi.wiring.package: javax.servlet >> [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] >> >> >> This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. >> >> I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? >> >> >> org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] >> Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui >> -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" >> org.openjdk.jmc.flightrecorder.ui [445] >> Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" > > Alex Ciminian has updated the pull request incrementally with two additional commits since the last revision: > > - Add tree and graph handlers to websocket server > - Revert whitespace changes in core/features.xml Marked as reviewed by bric3 at github.com (no known OpenJDK username). ------------- PR: https://git.openjdk.java.net/jmc/pull/306 From marcus.hirt at datadoghq.com Mon Sep 20 12:31:29 2021 From: marcus.hirt at datadoghq.com (Marcus Hirt) Date: Mon, 20 Sep 2021 14:31:29 +0200 Subject: OpenJDK JMC Committers Workshop? Message-ID: Hi all, As has been discussed in the latest jmc dev meeting, I've been thinking of maybe having a meetup for OpenJDK JMC developers and JDK serviceability folks. This could be arranged as an unconference, and I think we?d have enough to talk about for it to easily last two, maybe even three days. The initial idea was to do it mid November. Since we?re spread all over the place, I think it would be fair to alternate where we meet. My initial thought was Stockholm for the first meetup, but perhaps that is a bit dark and cold in November. Also, these are uncertain times, and we don?t know what is going to happen with Covid rates this autumn. If the last two years is any indication, we might be seeing additional travel constraints. So, what do you think? Should we have an annual OpenJDK JMC & Serviceability meetup? Is an unconference the right format? If so, when? And where would you like to meet for the first one? Looking forward to your input! Kind regards, Marcus From jpbempel at openjdk.java.net Mon Sep 20 15:53:56 2021 From: jpbempel at openjdk.java.net (Jean-Philippe Bempel) Date: Mon, 20 Sep 2021 15:53:56 GMT Subject: RFR: 7198: add websocket server that pushes data on selection updates [v6] In-Reply-To: References: Message-ID: On Thu, 16 Sep 2021 21:10:12 GMT, Alex Ciminian wrote: >> This PR adds a websocket server that pushes event data as JSON to all connected clients whenever the user updates their current selection in JMC. The server is disabled by default and can be enabled and disabled from JMC preferences. This is a rework of the proof-of-concept code in https://github.com/openjdk/jmc/pull/225 and uses the JSON serialiser introduced in #279. >> >> ![Screenshot 2021-09-15 at 12 08 56](https://user-images.githubusercontent.com/348973/133478041-ee436fbd-de3a-471d-955d-d0fe4cc854bf.png) >> >> ### Dependency management >> >> >> Brice pointed out that there are newer versions of the Jetty websocket server available under a different artefact name - I used the same version as required in the UI tests (`10.0.5`) and this made the build succeed in both eclipse and CLI. I've had to add SPI fly since it was required by jetty, but I don't really understand what it does. >> >> Initially I struggled to add the required dependencies to the project. Initially I was only testing in eclipse with the setup from #225 and it worked fine.`mvn package` also worked on the command line. However, the spotless task from our CI script failed with the following error: >> >> >> org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] because it is exposed to package 'javax.servlet' from resources javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] and jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] via two dependency chains. >> [ERROR] >> [ERROR] Chain 1: >> [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] >> [ERROR] require: (osgi.wiring.bundle=javax.servlet) >> [ERROR] | >> [ERROR] provide: osgi.wiring.bundle: javax.servlet >> [ERROR] javax.servlet [osgi.identity; osgi.identity="javax.servlet"; type="osgi.bundle"; version:Version="3.1.0.v201410161800"] >> [ERROR] >> [ERROR] Chain 2: >> [ERROR] org.openjdk.jmc.flightrecorder.ui [osgi.identity; osgi.identity="org.openjdk.jmc.flightrecorder.ui"; type="osgi.bundle"; version:Version="8.2.0.qualifier"; singleton:="true"] >> [ERROR] require: (osgi.wiring.bundle=org.eclipse.jetty.server) >> [ERROR] | >> [ERROR] provide: osgi.wiring.bundle; bundle-version:Version="10.0.5"; osgi.wiring.bundle="org.eclipse.jetty.server" >> [ERROR] org.eclipse.jetty.server [osgi.identity; osgi.identity="org.eclipse.jetty.server"; type="osgi.bundle"; version:Version="10.0.5"] >> [ERROR] import: (&(osgi.wiring.package=javax.servlet)(&(version>=4.0.0)(!(version>=5.0.0)))) >> [ERROR] | >> [ERROR] export: osgi.wiring.package: javax.servlet >> [ERROR] jakarta.servlet-api [osgi.identity; osgi.identity="jakarta.servlet-api"; type="osgi.bundle"; version:Version="4.0.0"] >> >> >> This is because the task is run with the `-P uitests` and something in the UI test configuration pulls in jetty.server 10.0.5. Since [the latest available version](https://mvnrepository.com/artifact/org.eclipse.jetty.websocket/websocket-server) for the jetty websocket server is `9.4.43.v20210629` we can't use the newer `10.x` for the transitive dependencies. >> >> I was able to work around this problem by setting bundle-version constraints in the `flightrecorder.ui` manifest. This makes all CI checks pass, but unfortunately it also breaks the JFR editor view in eclipse ?? >> >> >> org.osgi.framework.BundleException: Could not resolve module: org.openjdk.jmc.joverflow.ui [457] >> Unresolved requirement: Import-Package: org.openjdk.jmc.flightrecorder.ui >> -> Export-Package: org.openjdk.jmc.flightrecorder.ui; bundle-symbolic-name="org.openjdk.jmc.flightrecorder.ui"; bundle-version="8.2.0.qualifier"; version="0.0.0" >> org.openjdk.jmc.flightrecorder.ui [445] >> Unresolved requirement: Require-Bundle: org.eclipse.jetty.server; bundle-version="[9.4.43,10.0.0)" > > Alex Ciminian has updated the pull request incrementally with two additional commits since the last revision: > > - Add tree and graph handlers to websocket server > - Revert whitespace changes in core/features.xml application/org.openjdk.jmc.feature.flightrecorder/feature.xml line 3: > 1: > 2: