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 <[email protected]> 于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 <[email protected]> 于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 >> >
