You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Zili Chen <wa...@gmail.com> on 2019/09/24 13:05:51 UTC
Replace ZooKeeperThread with ThreadFactory
Hi ZooKeepers,
Back to ZOOKEEPER-837[1] we want to eliminate cycle dependency between
ZooKeeper and
ClientCnxn. Now the last usage of ZooKeeper in ClientCnxn is for retrieving
watches.
Couple with the advantage start a task using Runnable and ThreadFactory, we
can make this
last effort by re-implementing SendThread using Runnable and ThreadFactory,
passing
ZooKeeper instance on bootstrap method so that we eliminate cycle
dependency.
Furthermore, deep dive into Runnable overwhelms Thread argument, it could
make sense that
we replace ZooKeeperThread with ThreadFactory strategy. Generally we port
subclasses of
ZooKeeperThread to Runnable and at the place where we start the thread
previously, we
submit the Runnable to ExecutorServices built from ThreadFactory.
Implementation plan would be creating an umbrella JIRA to track all these
efforts, breaking down
by subclass and a dedicated subtask for introducing the framework using
ThreadFactory.
What do you think?
Best,
tison.
[1] https://issues.apache.org/jira/browse/ZOOKEEPER-837
Re: Replace ZooKeeperThread with ThreadFactory
Posted by Zili Chen <wa...@gmail.com>.
Even without port ZooKeeperThread to Runnable & ThreadFactory we can
eliminate
cycle dependency by pass zookeeper via ClientCnxn#start(extend this with a
ZooKeeper
parameter). But exclude exposing `this` in ZooKeeper constructor is always
a breaking
change that requires existing codes call ZooKeeper#start or sth. like this.
Best,
tison.
Zili Chen <wa...@gmail.com> 于2019年9月24日周二 下午10:06写道：
> One breaks is that we change SendThread's name when #startConnect.
> However, we can always use
> name xxx-SendThread and log host&port on #startConnect. Reflecting the
> host&port by thread name
> is one approach to show which host&port this client connect to, not the
> only approach.
>
>
> Zili Chen <wa...@gmail.com> 于2019年9月24日周二 下午9:05写道：
>
>> Hi ZooKeepers,
>>
>> Back to ZOOKEEPER-837[1] we want to eliminate cycle dependency between
>> ZooKeeper and
>> ClientCnxn. Now the last usage of ZooKeeper in ClientCnxn is for
>> retrieving watches.
>>
>> Couple with the advantage start a task using Runnable and ThreadFactory,
>> we can make this
>> last effort by re-implementing SendThread using Runnable and
>> ThreadFactory, passing
>> ZooKeeper instance on bootstrap method so that we eliminate cycle
>> dependency.
>>
>> Furthermore, deep dive into Runnable overwhelms Thread argument, it could
>> make sense that
>> we replace ZooKeeperThread with ThreadFactory strategy. Generally we port
>> subclasses of
>> ZooKeeperThread to Runnable and at the place where we start the thread
>> previously, we
>> submit the Runnable to ExecutorServices built from ThreadFactory.
>>
>> Implementation plan would be creating an umbrella JIRA to track all these
>> efforts, breaking down
>> by subclass and a dedicated subtask for introducing the framework using
>> ThreadFactory.
>>
>> What do you think?
>>
>> Best,
>> tison.
>>
>> [1] https://issues.apache.org/jira/browse/ZOOKEEPER-837
>>
>
Re: Replace ZooKeeperThread with ThreadFactory
Posted by Zili Chen <wa...@gmail.com>.
One breaks is that we change SendThread's name when #startConnect. However,
we can always use
name xxx-SendThread and log host&port on #startConnect. Reflecting the
host&port by thread name
is one approach to show which host&port this client connect to, not the
only approach.
Zili Chen <wa...@gmail.com> 于2019年9月24日周二 下午9:05写道：
> Hi ZooKeepers,
>
> Back to ZOOKEEPER-837[1] we want to eliminate cycle dependency between
> ZooKeeper and
> ClientCnxn. Now the last usage of ZooKeeper in ClientCnxn is for
> retrieving watches.
>
> Couple with the advantage start a task using Runnable and ThreadFactory,
> we can make this
> last effort by re-implementing SendThread using Runnable and
> ThreadFactory, passing
> ZooKeeper instance on bootstrap method so that we eliminate cycle
> dependency.
>
> Furthermore, deep dive into Runnable overwhelms Thread argument, it could
> make sense that
> we replace ZooKeeperThread with ThreadFactory strategy. Generally we port
> subclasses of
> ZooKeeperThread to Runnable and at the place where we start the thread
> previously, we
> submit the Runnable to ExecutorServices built from ThreadFactory.
>
> Implementation plan would be creating an umbrella JIRA to track all these
> efforts, breaking down
> by subclass and a dedicated subtask for introducing the framework using
> ThreadFactory.
>
> What do you think?
>
> Best,
> tison.
>
> [1] https://issues.apache.org/jira/browse/ZOOKEEPER-837
>