Impact of enabling Diagnostic context?

Java SDK
1

Hi all,

I noticed that while constructing the ClusterEnvironment, there is an option to enable the “Diagnostic context”

 LoggerConfig.Builder loggerConfig = new LoggerConfig
                                                .Builder()
                                                .enableDiagnosticContext(true);

Is there any performance penalties of enabling this? Or when should it be enabled?

2

Hi @yk010123,

You should enable this if you’re using SLF4J backed by a logger implementation that supports Mapped Diagnostic Context (MDC) parameters, and you want a “client context” you pass to each Couchbase request to be available as MDC entries. Here’s a small example:

collection.upsert(docId, content, upsertOptions()
    .clientContext(Map.of("color", "red")));

If enableDiagnosticContext is true, you can reference the “color” value in your log message pattern by using the placeholder %X{color} in your Log4j2 logging config file… or reference the whole MDC with %X.

(In a single-threaded application you could just set the MDC values on the thread yourself, but the Couchbase Java SDK dispatches requests on multiple internal threads. This special “client context” carries the context across the threads.)

If you 1. Enable the diagnostic context, 2. Pass a client context map, and 3. Configure Log4J to include the MDC in the log messages, any log messages emitted by the SDK while processing the request will include this extra context info about the specific request.

More info about MDC in Log4J2: Log4j – Log4j 2 Thread Context

There is some small performance overhead. Best way to know for sure is to test and measure.

Thanks,
David

1 Like
3

Thank you for the explanation David

Could you please clarify if this context will be available at the server side in any form for further tracing?

Thanks!

4

The clientContext map is not sent to the Couchbase server.