A better way to do thread renaming

["이희승 (Trustin Lee)"]

Service: New I/O, Old I/O, ...
Category: server boss, server worker, client boss, client worker, ...
Comment: local address, remote address, channel ID, ... (depending on
transport)

It might be a better idea to limit the allowed characters for service,
category, and thread ID (no whitespace for example.)

On 07/02/2010 04:35 PM, Galder Zamarreño wrote:
> What do service and comment contain?
> 
> Category I suppose it's client/server...etc.
> 
> On Jun 30, 2010, at 11:24 AM, 이희승 (Trustin Lee) wrote:
> 
>> Here's the new ThreadNamingDeterminer interface in 4.0:
>>
>>    http://is.gd/d9Kmq
>>
>> I did not use enum because the threads in some transports might not be
>> categorized into boss / worker.  What do you think?
>>
>> Cheers,
>> Trustin
>>
>> On 05/06/2010 12:33 PM, "Trustin Lee (이희승)" wrote:
>>> Hi Galder,
>>>
>>> I love your proposal.
>>>
>>> There are a couple more issues in Netty which requires
>>> backward-incompatible API changes including yours.
>>>
>>> Maybe it's time to begin Netty 4.0?
>>>
>>> Trustin
>>>
>>> galder at redhat.com wrote:
>>>> Hi Trustin,
>>>>
>>>> While debugging a netty server that's being exercised in unit testing with a netty based client, I've discovered that having ThreadRenamingRunnable.threadNameDeterminer set as static can cause a lot of confusion cos you end up seeing client decoder threads and server decoder threads with the same thread name.
>>>>
>>>> For example, in my logs I see things like this:
>>>>
>>>> 2010-04-30 12:39:27,993 1152  TRACE [org.infinispan.server.hotrod.HotRodEncoder$] (HotRodWorker-3-1:) Encode msg Response{messageId=8, operation=PutResponse, status=Success}
>>>> 2010-04-30 12:39:27,995 1154  TRACE [org.infinispan.server.hotrod.test.Decoder] (HotRodWorker-3-1:) Decode response from server
>>>>
>>>> The first line belongs to server code and the belongs to client code that's decoding server responses.
>>>>
>>>> Now, you could think that this might be a problem in my name delimiter implementation and indeed that's the case:
>>>>
>>>> infinispan.log:1552:2010-04-30 12:39:27,762 921   TRACE [org.infinispan.server.core.transport.netty.NettyTransport$] (pool-30-thread-1:) Thread name will be HotRodWorker-3-1, with current thread name being Thread[pool-30-thread-1,5,main] and proposed name being New I/O client worker #3-1
>>>> infinispan.log:1563:2010-04-30 12:39:27,755 914   TRACE [org.infinispan.server.core.transport.netty.NettyTransport$] (pool-15-thread-1:) Thread name will be HotRodWorker-3-1, with current thread name being Thread[pool-15-thread-1,5,main] and proposed name being New I/O server worker #3-1
>>>>
>>>> I hadn't realised that you'd name client and server threads differently. Hence, I'm being forced now to see if the proposed name has client or server in it to decide the final name. All in all, it seems rather error prone for me to have to do things like this, particularly if in the future you change the internal format.
>>>>
>>>> So, rather than having a method called determineThreadName(currentThreadName: String, proposedThreadName: String), I'd rather see something along these lines:
>>>>
>>>> determineThreadName(currentThreadName: String, threadType: Type, proposedThreadId: String, proposedNamePrefix: String)
>>>>
>>>> Type would be an enum of values: CLIENT_BOSS, CLIENT_WORKER, SERVER_BOSS, SERVER_WORKER
>>>>
>>>> proposedThreadId would be "3-1"
>>>>
>>>> proposedNamePrefix: "New I/O"
>>>>
>>>> Thoughts?
>>>> --
>>>> Galder Zamarreño
>>>> Sr. Software Engineer
>>>> Infinispan, JBoss Cache
>>>>
>>>> _______________________________________________
>>>> netty-users mailing list
>>>> netty-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>
>>
>> -- 
>> what we call human nature in actuality is human habit
>> http://gleamynode.net/
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
> 
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> 
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100702/c4e0a311/attachment.bin