Hi Kostya, I actually did not think about this too much when write the code. My gut feeling is that the benefit of using a thread pool is that you have jobs come and go and want to safe your own resource management overhead. In Mirror maker, there are only fixed number of mirror maker thread and all of them are long running. In that case there might not be too much difference between using Thread explicitly vs thread pool + runnable. Extending Thread might make some of the logic a little bit more explicit. Is there anything specific that makes you want to move to runnables?
Thanks, Jiangjie (Becket) Qin On 7/9/15, 4:17 AM, "Kostya Golikov" <johnysilv...@gmail.com> wrote: >I've skimmed through a source code of Mirror Maker and I see that it >relies >on raw threads ><https://github.com/apache/kafka/blob/7df39e0394a6fd2f26e8f12768ebf7fecd56 >e3da/core/src/main/scala/kafka/tools/MirrorMaker.scala#L285-L287>, >as opposed to "Runnable + Thread pool" combination. While former approach >is just as functional as later, I am quite curious why such decision was >done. Anything specific that prevents move to runnables?
