curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fangmin Lv (JIRA)" <>
Subject [jira] [Commented] (CURATOR-389) Factory and Default ThreadFactory inconsistencies and poor default thread names
Date Sat, 11 Mar 2017 23:19:04 GMT


Fangmin Lv commented on CURATOR-389:

Currently, EnsembleProvider only contains connection string, and this is the only information
in Curator that we can distinguish different Curator instance. Also using connection string
cannot distinguish different instances which are using the same connection string. It would
be nice if we allow the users to pass in the client id when initialize the CuratorFrameworkFactory.
In the future, this information may also be used as the connection identity for auth or throttling.

What's your ideas, [~randgalt]?

> Factory and Default ThreadFactory inconsistencies and poor default thread names
> -------------------------------------------------------------------------------
>                 Key: CURATOR-389
>                 URL:
>             Project: Apache Curator
>          Issue Type: Bug
>            Reporter: Michael Pawliszyn
>            Assignee: Fangmin Lv
> If you pass in a ThreadFactory to the CuratorFrameworkFactory that ThreadFactory is used
for both the Framework and the ConnectionStateManager. If no ThreadFactory is passed in two
thread factories are created so the threads are named based on what class is using the thread,
for example:
> "Curator-ConnectionStateManager-0" #62 daemon prio=5 os_prio=0 tid=0x00007f3d1272d800
nid=0x5466c waiting on condition [0x00007f3c46620000]
> "Curator-Framework-0" #418 daemon prio=5 os_prio=0 tid=0x00007f3d12d29800 nid=0x54ece
waiting on condition [0x00007f3ade6ef000]
> If there is more than one curator there is no indication on what Zookeeper connections
they are curating by looking at the thread dumps. Overall better default thread naming that
uses information from the EnsembleProvider would help investigations. 

This message was sent by Atlassian JIRA

View raw message