ramanathan1504 commented on issue #1976:
URL:
https://github.com/apache/logging-log4j2/issues/1976#issuecomment-4467721331
@jvz @ppkarwasz @vy
I’ve been looking into this issue, specifically regarding the performance
bottleneck when using OpenTelemetry with Asynchronous Loggers, and I'd like to
propose a backward-compatible migration path for `2.x`.
Currently, the reliance on `ThreadContext` to propagate `traceId` and
`spanId` across threads during Async logging forces map-copying, which
introduces memory/GC overhead in high-throughput applications.
To resolve this natively without waiting exclusively for `3.x`, would the
team be open to utilizing **Java 8 default methods** in the core `LogEvent`
interface?
**Proposed Approach for 2.x:**
We could introduce the W3C standard tracing fields directly to the
`LogEvent` interface with default implementations returning null:
```java
public interface LogEvent extends Serializable {
// ... existing methods ...
/**
* Returns the W3C standard Trace ID.
*/
default String getTraceId() {
return null;
}
/**
* Returns the W3C standard Span ID.
*/
default String getSpanId() {
return null;
}
/**
* Returns the W3C standard Trace Flags.
*/
default String getTraceFlags() {
return null;
}
}
```
Internally, classes like `RingBufferLogEvent` and `MutableLogEvent` could be
updated to actually store and pass these fields without relying on the
`ThreadContext` map.
**Addressing Architectural Concerns:**
1. **Backward Compatibility & OSGi:** Because Log4j 2.x now requires Java 8,
adding `default` methods avoids breaking existing custom `LogEvent`
implementations. Furthermore, OSGi Core specification and `bnd` baseline tools
correctly classify adding a `default` method as a **minor version bump**,
making this safe for the `2.x` release line.
2. **Framework Agnosticism:** While this issue mentions OpenTelemetry,
`traceId`, `spanId`, and `traceFlags` are not proprietary OTel concepts; they
are ratified **W3C Trace Context specifications**. By adding these, we aren't
coupling Log4j to a specific vendor, but rather elevating Log4j to natively
support modern W3C HTTP tracing standards.
If we implement this in `2.x`, it provides a highly performant, opt-in
bridge for users heavily relying on Async tracing today, and smoothly paves the
way for these to become mandatory fields in the `3.x` architecture.
***
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
