Just a thread name usually gives a too small amount of information to be able to identify a leaking issue, based on my experience. Reference leaks have a stackstace where we can clearly see what kind of logic it is related to, without it - it is very hard to find the cause. In the case of thread dumps - we also can say where we are in the logic based on a stack trace. In the case of logging for SEP threads I do not remember any cases when a thread name helped me. It can be helpful for flushing or repair threads (which ones are not SEP) where we have many messages and we may want to correlate them but for request processing threads the amount of logs is really small to get even one per request.
In any case, if other people think that the current value is more beneficial I would not insist too much on changing the default, taking in account the ability to change it. On Wed, 10 Dec 2025 at 22:40, Josh McKenzie <[email protected]> wrote: > I’ve considered submitting a ticket to change the default for this option. > > Co-locating this kind of debug information with log level and tracing > reference leaks seems like it could be a nice gesture to our users. And > whatever else we may have rustling around (undocumented -D flags, other > things in the .yaml, etc) > > > On Wed, Dec 10, 2025, at 5:08 PM, Dmitry Konstantinov wrote: > > I’ve considered submitting a ticket to change the default for this option. > > > -- Dmitry Konstantinov
