Minor Description
While debugging a test application I was confused to see a number of log lines where the StreamThread name appeared twice but had a different thread id/index in the same message. For example:
[INFO ] 2024-11-19 04:59:14.541 [e2e-963c5b74-0353-4253-bdf2-b71881d9d9f2-StreamThread-1] StreamThread - stream-thread [e2e-963c5b74-0353-4253-bdf2-b71881d9d9f2-StreamThread-3] Creating thread producer client
Generally you would expect that the actual Logger prefix (the first thread name, in this case StreamThread-1) is the same as the LogContext prefix (the second thread name, ie the StreamThread-3 in this example). I dug into it and figured out that this happens for all of the messages logged during the StreamThread#create method, ie before the new thread is actually created. What happened was StreamThread-1 had actually died, and started up a new thread (StreamThread-3) to replace itself before shutting down. So we were logging things about StreamThread-3, but from StreamThread-1.
While this doesn't necessarily harm anyone, it's quite confusing to see and requires extensive knowledge of Streams to understand (a) that it's not a bug, and (b) which thread the messages are actually referring to. It also makes things harder to parse and read – for example I often filter logs on the Logger prefix to gather everything related to a particular thread and eg the clients it owns. The name of the currently executing thread is more reliable and gathers everything whereas not every logger is configured with the LogContext prefix (eg `stream-thread [e2e-963c5b74-0353-4253-bdf2-b71881d9d9f2-StreamThread-3]`).
We should move things out of the static StreamThread#create method and into the thread constructor to make the logging consistent and reliable.