Federico Mariani created CAMEL-23383: ----------------------------------------
Summary: Add JFR runtime instrumentation for exchanges,
processors, and endpoints
Key: CAMEL-23383
URL: https://issues.apache.org/jira/browse/CAMEL-23383
Project: Camel
Issue Type: New Feature
Components: camel-jfr
Affects Versions: 4.20.0
Reporter: Federico Mariani
The existing _camel-jfr_ module (CAMEL-16056) only instruments startup/shutdown
lifecycle via _StartupStepRecorder_. There is no runtime instrumentation,
per-exchange, per-processor, or per-endpoint JFR events are not emitted.
Libraries like
[hibernate-jfr|https://github.com/hibernate/hibernate-orm/tree/main/hibernate-jfr]
demonstrate the value of per-operation JFR events for production diagnostics.
Camel should offer the same capability for route execution.
Proposed JFR events:
- *CamelRouteEvent*: routeId, exchangeId, elapsedTime, failed
- *CamelProcessorEvent*: exchangeId, routeId, processorId, processorType,
elapsedTime
- *CamelEndpointSendEvent*: exchangeId, endpointUri, elapsedTime, failed
- *CamelExchangeEvent*: exchangeId, routeId, endpointUri, elapsedTime, failed
- *CamelExchangeFailedEvent*: exchangeId, routeId, exceptionType,
exceptionMessage
- *CamelRedeliveryEvent*: exchangeId, routeId, attempt, maxAttempts
Implementation approach proposal:
Camel already has the interception infrastructure — InterceptStrategy,
EventNotifier, and RoutePolicyFactory used by _camel-opentelemetry2_ for OTel
spans. The JFR implementation would follow the same wiring but emit JFR events
instead.
Why JFR:
- Zero overhead when recording is disabled (JVM JIT short-circuits
begin()/commit())
- No external collector needed, open the .jfr file in JDK Mission Control
- Captures JVM-level context (CPU, memory, GC, threads) in the same recording
alongside Camel events
- Safe for always-on production use
This could either extend the existing *camel-jfr* module or be a new
*camel-jfr-runtime* module.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
