ThreadRenamingRunnable

[Trustin Lee]

On Sat, Apr 18, 2009 at 10:32 PM, Trustin Lee <tlee at redhat.com> wrote:
> Hi Nick,
>
> On Fri, Apr 17, 2009 at 6:43 PM, Nicholas Clare <nickclare at gmail.com> wrote:
>> Hi all,
>>
>> I've been reading through the Netty sources, to try to get a better
>> idea of what's happening under the covers. One thing that has
>> interested me is the use of ThreadRenamingRunnable. I'm currently
>> planning a system that would use Netty for two different things at the
>> same time. So there will be a Netty server socket for receiving client
>> connections, and then another Netty server and client for
>> intra-cluster communication. So my question is, would it be possible
>> to disable Netty from renaming my threads, so that I can name them
>> myself. Otherwise I imagine I'll have many "New I/O server worker
>> #X-Y" threads, which would be harder to debug than "Cluster Worker
>> #X", and "Client Worker #Y", in my opinion. It's not really a very
>> serious problem, but I'm just wondering why it was decided to do the
>> renaming, rather than allowing people to name their own threads?
>
> Because people just use Executors.newCachedThreadPool() and then their
> thread names don't have much meaning?
>
> Actually you will have 'New I/O server worker #X-Y' and 'New I/O
> client worker #X-Y', so you will be able to recognize which threads
> are dedicated to cluster or client in your specific case.
>
> However, I agree with you that it would be nice if 'New I/O
> (client|server) (boss|worker)' could be customizable.  Perhaps
> ThreadRenamingRunnable could be improved so that it does not rename
> the current thread completely but append additional information to the
> current thread name if a user set the thread name already?

Hmm.. but how do I determine 'if a user set the thread name already?'
That's a tricky problem..

— Trustin Lee, http://gleamynode.net/