HelixTaskExecutor threads are not named properly after re-initing

[klsince]

Describe the bug

Version: 1.3.1

Normally, the HelixTaskExecutor thread pool uses the following pattern to name the threads from the pool, with a thread id suffix. This makes it easy to tell the threads apart in the pool for debugging.

HelixTaskExecutor-message_handle_thread_31

Recently, we found those threads got named as below when Helix sessions got reconnected, like due to long GC pauses. As all threads got the same name, making debugging much harder.

HelixTaskExecutor-message_handle_STATE_TRANSITION

To Reproduce

This should be reproduced by causing loss of session and reconnect. In particular to get this Init() method to run. As we saw this INFO logs before the threads got renamed.

// HelixTaskExecutor.java
...
  void init() {
    LOG.info("Init HelixTaskExecutor");
...

Expected behavior

Continue to have this naming pattern after re-initing the HelixTaskExecutor

HelixTaskExecutor-message_handle_thread_31

Additional context

We may consider to refine the logic to re-init the pool

  void init() {
    LOG.info("Init HelixTaskExecutor");

   ...       ExecutorService newPool = Executors.newFixedThreadPool(item.threadPoolSize(),
            r -> new Thread(r, "HelixTaskExecutor-message_handle_" + type)); <-----------------
      ...
  }

by continuing to use this naming pattern. And I think we don't even need to reset thread_uid counter, so it'll be easy to tell if a thread pool gets created.

"HelixTaskExecutor-message_handle_thread_" + thread_uid.getAndIncrement()));

Thanks!