Fix bug in resetting ByteArrayZkClient

[narendly]

Issues

• My PR addresses the following Helix issues and references them in the PR description:

Fixes #1479

Description

• Here are some details about my PR, including screenshots of any UI changes:

It was discovered that even though there was a routing data change, _byteArrayZkClient was not being created anew using the newly read routing data. This would cause issues with the zookeeper endpoints provided through Helix REST. This change cleans up some internal methods and ensures that the byte array zk client gets nullified every time there is routing data change.

More specifically, the code was closing byteArrayDataAccessor but not byteArrayZkClient. This meant that the same byteArrayZkClient would be used even though everything was reset and routing data was updated. Hence, the data accessor was not really being created from scratch. This change makes sure that the underlying byteArrayZkClient gets closed and nullified upon routing data change.

Tests

• The following tests are written for this issue:

TestRoutingDataUpdate

• The following is the result of the "mvn test" command on the appropriate module:

[INFO] Tests run: 171, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 201.923 s - in TestSuite
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 171, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  03:26 min
[INFO] Finished at: 2020-11-12T15:00:27-08:00
[INFO] -----------------------------------------------------------------------

Documentation (Optional)

• In case of new functionality, my PR adds documentation in the following wiki page:

(Link the GitHub wiki you added)

Commits

• My commits all reference appropriate Apache Helix GitHub issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":
  1. Subject is separated from body by a blank line
  2. Subject is limited to 50 characters (not including Jira issue reference)
  3. Subject does not end with a period
  4. Subject uses the imperative mood ("add", not "adding")
  5. Body wraps at 72 characters
  6. Body explains "what" and "why", not "how"

Code Quality

• My diff has been formatted using helix-style.xml
  (helix-style-intellij.xml if IntelliJ IDE is used)

[junkaixue]

Overall, it looks good to me. But could you elaborate more in description or in the issue? I am still confused to see why the byteArrayClient is not created could cause what kind of the problem? I am just confused about the how the clean up can solve the problem.

[narendly]

I added:

More specifically, the code was closing byteArrayDataAccessor but not byteArrayZkClient. This meant that the same byteArrayZkClient would be used even though everything was reset and routing data was updated. Hence, the data accessor was not really being created from scratch. This change makes sure that the underlying byteArrayZkClient gets closed and nullified upon routing data change.

Let me know if this is clearer!

[junkaixue]

Thanks @narendly ! Now I understand the missing part of the client. So it means the underneath byteArrayZkClient could maintain stale info instead once everything is reset.

LGTM.