[slf4j-dev] [JIRA] Updates for SLF4J-531: MDC should support stack values identified by key

[QOS.CH (JIRA)]

SLF4J / SLF4J-531 [Open]
MDC should support stack values identified by key

==============================

Here's what changed in this issue in the last few minutes.

There is 1 comment.

View or comment on issue using this link
https://jira.qos.ch/browse/SLF4J-531

==============================
 1 comment
------------------------------

Ceki Gülcü on 16/Apr/22 11:07 AM
When discussing this with [~pkarwasz], I assumed that we were talking about a map of type {{Map<String, Dequeue<String>>}} where thread-local stacks were accessed by a key. Let S1 designate this type, i.e. {{Map<String, Dequeue<String>>}}.

It looks like log4j2's implementation proposes a single stack accessed without a key, that is with a structure of type {{List<String>}}. Let S2 designate the type {{List<String>}}.


So, there is the question of which data structure is better, i.e. S1 or S2. Let Q1 designate this question.

Let M1 designate type {{Map<String, String>}} stored in a thread local. There seems to be wide agreement on the usefulness of this data structure commonly called as MDC.

There is also the second question, call it Q2, of whether the same key can or cannot be used to access data in both data structures M1 and S1. If M1 and S1 are separate structures, it makes sense to allow the same key to be used to access different and separate data in these to structures. If however, M1 and S1 are merged into a single super data structure, then the same key can access only a single data point.

Are we discussing Q1 or Q2 or both?

Anyway, assuming nested data is useful, it seems pretty natural to further assume that there will be multiple nested data values. These must be accessed separately by key. A no key solution implicitly assumes that nested data is *not* useful. Indeed, this was my position for a long time. However, if you need to manage spandIds then S1 is the obvious data structure. Moreover, given that spandIds can be critical in some applications, it is safer to assume that there may be several parallel spandId uses which will need to be referenced by different keys. 

I'll stop here before this comment gets too unwieldy.


==============================
 This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)