[Feature]: jfr event streaming

[maxandersen]

Problem Statement

I'm looking for being able to connect to a running app and read the jfr events from jfr event streaming (JEP-349) and see live events come in, be able to filter and be able to possibly query/aggregate on them continouslyl

Proposed Solution

connect command which will list active jdks running and be able to connect, connect <id> would connect and start receiving events.

Maybe have tail to continouly trace events and query and other existing commands should be able to work on the received data as if it had been read from a .jfr file

Alternatives Considered

No response

API Example

Breaking Change?

Not sure

Priority

Critical - blocking my use case

Additional Context

i like to use jfr more and beyond "just" profiling but also as active use for structured logging without relying on additional libraries.

I'm happy to help contribute/work/test on this but can't currently commit to it so not putting a checkbox in that checklist before knowing a bit more :)

Checklist

• I have searched existing issues and this feature hasn't been requested
• I have checked LIMITATIONS.md to see if this is a known limitation
• I would be willing to contribute this feature

[jbachorik]

Thanks for this request, and for the detailed use case. Using JFR as a structured logging mechanism is a compelling pattern that goes beyond the typical profiling workflow.

We looked at the feasibility carefully, and the short answer is: this is doable, but not in one step. Here is what we think is realistic and what the tradeoffs are.

What JEP-349 gives us

The JDK's EventStream.openRepository() (Java 14+) is the right foundation. It reads live events from a running JVM's on-disk repository with no socket or JMX connection required for local processes. The live-streaming support would be built as a new backend plugin alongside the existing jfr-shell-jdk and jfr-shell-jafar plugins, so it stays optional and does not affect users who only need file-based analysis.

Phase 1 (local attach, raw tail)

The first milestone would deliver:

• A connect command that lists running JVMs on the local machine (using hsperfdata filesystem scanning, no jdk.attach module required) and attaches by PID
• A tail [filter] command that prints events as they arrive until Ctrl-C
• The existing open / file-based workflow remains completely unchanged

Drawback: the existing query pipeline (groupBy, stats, filter, flamegraph) would not work against a live session in this phase. The query engine today makes a single pass over a finite dataset; adapting it to unbounded streams with windowed aggregations is a separate, non-trivial piece of work.

Phase 2 (live query support)

Extend the JfrPath evaluator to support windowed or cumulative aggregation against a live session, so that commands like events/jdk.ExecutionSample | groupBy(sampledThread/javaName) work continuously and re-emit results on a configurable interval.

Phase 3 (remote + MCP)

Remote attachment via RemoteRecordingStream over JMX, and buffered pull tools for the MCP server (jfr_stream_open / jfr_stream_next / jfr_stream_close). Note that true push streaming is not supported by the MCP protocol, so the MCP surface would be a buffered pull API rather than a real-time stream.

Open question for you

Would Phase 1 (local attach, tail with basic per-event filtering but no aggregation) cover your structured-logging use case? If the primary need is "see events as they happen and filter by type or field value", Phase 1 gets there. If continuous aggregation (counts, groupings, stats over a rolling window) is essential from day one, we should design Phases 1 and 2 together to avoid reworking the session model twice.

Also, is local-only (same machine) sufficient, or do you need remote attachment to a JVM running on a different host?

[maxandersen]

+1 on phased approach as having just a start will help.

local-only is fine for my usecase but could for sure future use of remote attach but not necessary at first.