ThreadRenamingRunnable

[Trustin Lee]

On Sat, Apr 18, 2009 at 10:56 PM, Nicholas Clare <nickclare at gmail.com> wrote:
> On Sat, Apr 18, 2009 at 3:38 PM, Trustin Lee <tlee at redhat.com> wrote:
>> 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..
>
> I was thinking of suggesting that you only change it if the user
> hasn't already, but then I couldn't think of a way to do that
> properly, either. So I'll keep thinking about it, and let you know if
> I have any ideas.

We are on the same page at least.  That's a great thing. :-)

Cheers,

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