CODEWITHSUNDEEP
javamultithreadingthread-safetythreadpool
Dojo
Dojo

Reputation: 5684

Thread.setName(name) caveats

I have a multi threaded client server application which uses Sockets. When a new connection is found, further execution is transferred to a new thread using the new Executors thread pool.

I want to log the client id in all logging statements for that client. The problem is that I don't want to modify method signatures just to pass the client id.

The solutions that I thought of are:

  1. Using ThreadLocal to hold client value.
  2. In run(), I can set the client id into Thread using Thread.currentThread().setName(clientId);

First one should work. But I like second option because a. I can find the client id from the debugger b. The logger library can be configured to show thread name. So no changes would be required to the log statements and it would also work for loggers inside libraries.

What are the caveats for using thread.setName() apart from those mentioned in the javadoc? How does it affect performance? The peak frequency of calling thread.setName() would be about 200 per second and average about 0.3 per second.

Upvotes: 9

Views: 5780

Answers (3)

Stephen C
Stephen C

Reputation: 718886

What are the caveats for using thread.setName() apart from those mentioned in the javadoc? How does it affect performance? The peak frequency of calling thread.setName() would be about 200 per second and average about 0.3 per second.

Performance should not be a significant issue. Thread.setName() does a security check and then copies / sets an attribute. The security check should be cheap unless your code is privileged code running in a security sandbox that forbids unprivileged calls to the Thread.setName() method.

In Java 9 and later, setName is going to tell the OS to change the native thread's name. For Linux, Solaris, AIX and BSD (e.g. MacOS) this is done via a call to pthread_setname_np which makes a syscall under the hood. With Windows, it does some weird thing with the Windows debugger ... and only works if there is a debugger already attached. In Java 8, no attempt is made to change the native thread name.

The only other caveat I can think of is that thread names changing all of the time could be confusing if you are trying to debug threading behavior; e.g. looking at thread dumps, etc.o

Upvotes: 3

rhu
rhu

Reputation: 963

If you use Log4j, there is a specific mechanism for handling this type of logging pattern, split between two classes org.apache.log4j.NDC and org.apache.log4j.MDC ('Nested and Mapped Diagnostic Contexts').

Have a browse at NDC vs MDC - Which one should I use? to see which is the best to use for your particular situation.

Here's another link which describes MDC use in a bit more practical detail: Build Flexible Logs With log4j - O'Reilly Media

Note that underlying storage mechanism MDC/NDC uses (I believe) is ThreadLocal anyway.

Upvotes: 4

m.genova
m.genova

Reputation: 377

I use your second approach in developed software (printserver), but threads have a long run so "setName()" don't add latency in processing. The logging phase is very good showing thread name.

I think "setName()" is a problema in two case:

  1. very short run;
  2. thread used by more actors with different id (but this is not your context, or not?).

bye.

Upvotes: 1

Related Questions