[maven-release-plugin] prepare release helix-1.0.0

Revert "[maven-release-plugin] prepare release helix-1.0.0"

This reverts commit a71153cfe1e188b0a870a7b113ac3b112cb25a47.

Revert "[maven-release-plugin] prepare for next development iteration"

This reverts commit 0fd189e099389ce8859870212f7539124e0b017f.

Revert "Add async call retry to resolve the transient ZK connection issue. (#970)"

This reverts commit 96ebb27c23004a7a69dc4799b14586ff82d53c9e.

Rearrange zookeeper imports in pom.xml (#995)

This commit makes sure pom.xml is up to date in preparation for the 1.0.X release.

Add async call retry to resolve the transient ZK connection issue. (#970)

If any exceptions happen during the async call, the current design will fail the operation and may eventually return a partial result.
This change makes the ZkClient retry operation if the error is because of a temporary ZK connection issue (CONNECTIONLOSS, SESSIONEXPIRED, SESSIONMOVED).
So the async call has a larger chance to finish the operation. Note that if the exception is due to business logic, the async call will still fail and the right return code will be sent to the callback handler.

[maven-release-plugin] prepare for next development iteration

[maven-release-plugin] prepare release helix-1.0.0

Enable helix-front for release

fix version comparison issue in compatibility check stage (#992)

Stabilizing 4 flaky tests (#981)

Four tests has been stabilized in this commit.

These tests are:
1-TestJobFailure
2-TestRebalanceRunningTask
3-TestTaskRebalancerStopResume
4-TestTaskSchedulingTwoCurrentStates

TestJobFailure was unstable because we get ExternalView of a resources and if the ExternalView is not populated yet by the controller, we hit NullPointerException.

TestRebalanceRunningTask was unstable. In this PR, we make sure that the master is existed in two different nodes (master is switched to new instance) and then we check the assigned participants.

TestRebalanceStopAndResume was unstable because of Thread.Sleep usage. Instead of stopping the workflow after some time, we first make sure that workflow and job is IN_PROGRESS and then stop the workflow.

TestTaskSchedulingTwoCurrent has been stabilized by making sure that master has been switched to new instance after modifying IS. After that we make sure that task is assigned to the correct instance and make sure it does not switched to new instance and cancel is not being called incorrectly.

Add 1.0.0 release folder and release notes

Fix failed tests in helix-rest (#966)

In tests: TestZkRoutingDataWriter and TestZkRoutingDataReader, the zkClient is trying to read/write ZNRecords, however, zkClient's serializer is not a ZNRecordSerializer but a BasicZkSerializer. So when read/write a ZNRecord, a ZkMarshallingError is thrown and causes the tests failed.

Improve logging for isClusterSetup (#968)

If isClusterSetup fails, we don't get the errorMsg. This PR improves that behavior by making it a warn log.

Change DistributedLock interface APIs (#961)

Change DistributedLock interface API names to follow Java convention

Rename interface HelixLock to DistributedLock

Remove dependency of LockInfo on HelixProperty

Clean up code

Created LockScope interface

refactor LockInfo and some updates on the HelixLockScope

Added cluster level to HelixLockScope and convert lock path to uppercase

simplified acquireLock logic

Fixed lock path generation

Changed method doc for releaseLock in HelixLock interface

A few fixes on syntax

Added test to acquire lock simultaneously

Fixed logic of release and isOwner

Added unit tests for Helix nonblocking lock

created Helix nonblocking lock based on zk

Added details in comments

Added LockInfo interface

Created Helix distributed lock design (apache#702)

Created Helix distributed lock interface (#703)

Added LockInfo interfaces.

Add Helix Distributed lock module (#673)

Add Helix Lock module.

use new ZNRecord and update test

Move routing table provider initialization (#946)

This PR moves the initialization of routing table provider to before class so it is initialized before any updates. Also, added several checks into the validation method to cover some edge cases.

Add registration logic for CustomizedView listeners (#944)

In this commit, a new logic is added which target the scenario where user
disables and enables specific types. In this case, since the CustomizedView
path for that type is removed by the controller, the router looses its
listener. In this commit, we added root change lister and re-registers the
listens again.

Add cache update/delete in customized view aggregation stage (#934)

Add customized view cache update in customized view aggregation stage. This is to ensure that the cache does not have stale data

fix customized state provider (#928)

Modify customized state provider factory. The new factory can build a customized state provider with either Helix own manager or a customer input manager.

Add integration test to customized view aggregation (#912)

The integration test involves components: update customized state using customized view provider, and use routing table provider to get customized view snapshots which are aggregated in controller.

Replace customized view cache with property cache (#869)

In this commit, the custom implementation of customized view cache
has been replaced with property cache implementation.

minor fix for customized view aggregation (#917)

Fix minor issues in customized view aggregation logic and add some more tests.

Co-authored-by: Meng Zhang <mnzhang@mnzhang-mn1.linkedin.biz>

Add new stages in Helix generic controller for customized view aggregation. (#851)

Add extra stages and pipelines in controller for customized state computation and customized view aggregation.
Add refresh logic in resource data provider for customized view related data refresh.
Add customized state event handling in CallbackHandler.
Add integration test for customized view aggregation.
Modify existing tests to verify new logic.

Co-authored-by: Meng Zhang <mnzhang@mnzhang-mn1.linkedin.biz>

Complete the Routing Table Provider for CustomizedView (#834)

In this commit, the routing table provider has been changed in a way to include customized view feature.

Add two stages for customized state view aggregation. (#888)

1. One stage is the computation stage for customized state. It takes the Zookeeper data of customized states and converts them to the formatted output used by the other stage.
2. The other stage is customized view aggregation stage. It will take the output from the customized state computation stage, and output the customized view to Zookeeper.
3. The two stages together compute the customized view from the customized states.
4. Unit tests are added to verify the correctness of the two stages.

update cache functions for customized view aggregation (#887)

Update some cache functions for customized view aggregation

Use updater to update customized state for concurrency control (#859)

Currently the update customized state method is made synchronized for concurrency control. This commit modifies the implementation of update to leave the responsibility of concurrency control to ZooKeeper by using updater to update the customize state. With delete method already implemented with updater, we can prevent unexpected change of the customize state data.

rename custmized state aggregation config to customized state config (#885)

Rename customized state aggregation config to customized state config for future extendibility.

Co-authored-by: Meng Zhang <mnzhang@mnzhang-mn1.linkedin.biz>

Add intermediate storage for customized state (#827)

1. Implement a participant state cache for generalizing functions in both current state cache and customized state cache.
2. Implement an intermediate data structure to store the result of customized state computation and prepare the data to be the format that can be used by customized view computation later.

Improve CustomizedStateProvider tests (#840)

Add tests to make CustomizedStateProvider tests comprehensive.

add listener and config for customized view aggregation (#815)

Add listeners for customized state and customized state aggregation config in Helix managers

Add basic functionalities for RoutingTableProvider for CustomizedView (#814)

This commit contains the basic functionalities for
CustomizedView RoutingTableProvider.

Here are the new added functionalities:
1- CustomizedViewChangeListener
2- Addition of CustomizedView to helix PropertyType and PropertyKey
3- Implementation of CustomizedView cache.
4- Registering CallbackHandler for CustomizedView.

Implement Helix API for updating customized state (#729)

Implement Helix APIs in CustomizedStateProvider for customers to operate on their own customized state. The available operations include update, get, and delete. To use CustomizedStateProvider, Helix user should initialize its factory and pass required parameters.

Add REST API to add, remove and update CustomizedStateAggregationConfig (#797)

In this commit the below REST APIs have been added.
1- addCustomizedStateAggregationConfig
2- removeCustomizedStateAggregationConfig
3- getCustomizedStateAggregationConfig
4- updateCustomizedStateAggregationConfig
Tests have been added to check the functionality of these REST APIs.
Also some of the depricated calls have been updated.

Add java API to add or remove CustomizedStateAggregationConfig (#792)

In this commit the below APIs have been added.
1- addCustomizedStateAggregationConfig
2- removeCustomizedStateAggregationConfig.
3- addTypeToCustomizedStateAggregationConfig
4- removeTypeFromCustomizedStateAggregationConfig
Tests have been added to check the functionality of these APIs.

add CustomizedStateAggregation config (#776)

Add CustomizedViewAggregation as a cluster level config. This config defines the types of customized states that will be aggregated by Helix controller to generate a customized view. If Helix customers would like to have an aggregated view generated for their own states, they will need to add the type of the state to the list view in this config.

Add the CustomizedView Helix property (#723)

This commit contains the bare minimum properties for CustomizedView Helix property.

Fix routing data refreshing in MSDS (#955)

testSetNamespaceRoutingData is flaky because namespace is removed when refreshing routing data. It is caused by race condition between the read request after updating and data change callback to refresh routing. And routing data cache should not be refreshed if writing routing to ZK fails.

Fix Regression on Flaky Tests in TestResourceAccessor (#959)

The previous fix to TestResourceAccessor (stopping all mock controllers) might have affected other tests. A better approach, instead of stopping all controllers, is to pause the clusters instead.

Fix unexpceted partition movements in the CrushEd strategy. (#941)

This is a workaround fix to ensure backward compatibility. An additional cache map is used to keep the stable partition list so as to remove the randomness in the algorithm input.
Note that the right fix would be cleaner that we sort the list inside the strategy class. However, that will also change all existing cluster assignments in production.

Fix unstable test TestRebalancePipeline.testMsgTriggeredRebalance() (#953)

Remove all the hardcoded thread sleeps in the test case. Replaced with Verifiers.

Fix ZkHelixPropertyStore loses Zookeeper notification issue (#924)

ZkHelixPropertyStore loses ZK notification after session expires.
THe issue was caused by a bug in Share ZkClient code path. More
specifically, Share ZkClient would not call fireAllEvent when ZK
session expires. Thus, ZkHelixPropertyStore would not install
watches for corresponding ZkPath. Thus, lose Zookeeper
nofiticaition when changes happens.

Co-authored-by: Kai Sun <ksun@ksun-mn1.linkedin.biz>

Simplify logging

Fix TestCrushAutoRebalanceNonRack failure of dropping instance

Add integration test for Helix Java APIs using different MSDS endpoints (#948)

To make sure Helix Java API is connecting to the correct MSDS endpoint, we add an integration test. This test verifies that each API only connects to the configured MSDS endpoint but not other endpoints.

Change thread pool used for TTL-based GC in ZkBucketDataAccessor (#945)

ZkBucketDataAccessor supports TTL-based garbage collection of stale versions. We create a thread pool for this of size 1, but the way the thread pool is created currently may not guarantee strictly sequential execution of GC timer tasks, which may cause unexpected GC behaviors. This commit uses Executors.newSingleThreadScheduledExecutor()to create the GC thread pool with a sequential execution guarantee.

Note: another way to do this is to implement a Bounded event queue-based GC, but Java already provides this queue-based model in Executors interface - we want to try our best at avoid reinventing the wheel.

Fix flaky resource accessor tests (#935)

This PR fixes the flaky tests in TestResourceAccessor, namely testPartitionHealth and testResourceHealth. The tests have been failing because the external views created during the tests could be sometimes removed before the health check, causing health checks to fail. How to reproduce: add time delay before health check calls will always fail the test cases.

We believe that the reason behind external view removal is due to the controllers, and disabling the controllers on the test clusters has made the tests pass even with the time delay.

Fix MetadataStoreDirectory routing data cache refresh bug (#933)

This PR ensures that routing data cache is cleared before updating in ZkMetadataStoreDirectory. Also, this PR fixes an edge case during TrieRoutingData creation when no zk realms has any sharding key.

Fix getClusters() in ZKHelixAdmin for multi-zk mode (#916)

This PR fixes the logic in getClusters() so that it works in a multi-zk environment. On multi-zk mode, the API will query for raw routing data from MSDS and produce a list of all clusters in the namespace. The behavior for single-zk mode remains the same for backward-compatibility.

Make multiZkEnabled configurable in HelixRestNamespace (#915)

It was observed that we need more fine-grained control over this multiZkEnabled config because there could exists namespaces with differing modes. Because multiple namespaces may be co-deployed, we cannot simply make it a system config.

Make Helix REST realm-aware (#908)

Helix REST needs to start using a realm-aware ZkClient on multi-zk mode. Also it needs to become a listener on routing data because we don't want to restart the HelixRestServer every time we update the routing data.

Changelist:

Make ServerContext listen on routing data paths if run on multi-zk mode
Make HelixRestServer use RealmAwareZkClient (FederatedZkClient) on multi-zk mode

Use Java Generics and inheritance to reduce duplicate code in Helix API Builders (#899)

This PR removes duplicate logic and refactors the ZK helix API Builder logic into one single public abstract class so that other Builders can inherit from it. It makes use of Builder inheritance and Java Generics. This PR promotes code reuse and better craftsmanship.

Fix setRoutingData boolean handling; fix leader forwarding url construction (#902)

This PR makes SetRoutingData respect the return value of the underlying function; it also fixes request forwarding urls, allowing ports and endpoint prefixes to be added.

Add integration tests for Helix Java APIs (#892)

This commit adds a comprehensive integration test for Helix Java APIs. All Helix Java APIs are tested using regular resource rebalancing and task framework.

Make ZkUtil realm-aware (#896)

There were some places in the code that were missed in previous PRs. This makes ZkUtil realm-aware by replacing HelixZkClient with RealmAwareZkClient.

Make ZkBucketDataAccessor realm-aware (#894)

Because Helix Controller now uses WAGED rebalancer as the default rebalancer, it tries to create an instance of ZkBucketDataAccessor. This will fail unless ZkBucketDataAccessor was also made realm-aware. We can simply use a FederatedZkClient here since BucketDataAccessor does not support ephemeral operations.

Update listClusters() in ZkHelixAdmin (#895)

This PR updates getClusters() in ZkHelixAdmin in realm-aware mode. It is difficult to reason about getting all clusters - and this method, on single-realm mode, is also broken anyways because in the case users create nested clusters, this method will end up returning nothing. This update is backward-compatible for single-realm users.

Ideally, users should use Metadata Store Directory Service to get the list of all clusters.

Reformat ZkBaseDataAccessor (#893)

Changelist:
1. Add generic type markers to Builder (<T>)
2. Fix a bug in validate function
3. Default to ZNRecordSerializer to preserve existing behavior

Make ZKHelixAdmin and ZKHelixManager Realm-aware (#846)

To make Helix Java APIs realm-aware, we need to make both ZKHelixAdmin and ZKHelixManager realm-aware. This commit adds a Builder to set client config and connection config for building realm-aware ZkClients underneath.

Make ZkBaseDataAccessor realm-aware (#855)

This commit makes ZkBaseDataAccessor realm-aware by building according realm-aware ZkClients in the constructor. A Builder is provided to set realm-aware client config and connection config.

Make ZkHelixClusterVerifier and its child classes realm-aware (#867)

Changelist:
Make sure constructors accept RealmAwareZkClient
Add Builders in each child class of ZkHelixClusterVerifier so that ZkClient configs are configurable and uses realm-aware ZkClient APIs

Make ZkCacheBaseDataAccessor and ZkHelixPropertyStore realm-aware (#863)

This commit makes both ZkCacheBaseDataAccessor and ZkHelixPropertyStore realm-aware by choosing the appropriate realm-aware ZkClients in the constructor. Also, we add a Builder here to give users options to set Connection config and Client config.
Note that ZkHelixPropertyStore extends CacheBaseDataAccessor so there is no change needed.

Make ClusterSetup realm-aware (#861)

We make ClusterSetup, a Helix Java API, realm-aware so that this could be used in a multi-ZK environment.

Changelist:
Add a Builder to enable users to set internal ZkClient parameters
Add the realm-aware behavior in existing constructors
Update ConfigAccessor to reflect the change in the logic

Add rerunFailingTestsCount config to surefire-plugin (#865)

It was observed that if build fails (if there is a test failure), then not all of the test goals are executed. There are currently two goals: default-test (single ZK) and multi-zk. If default-test has any test failures, we won't ever see multi-zk get executed, and this is a problem because we don't get to run the test suite in a multi-zk setup.

This config change is a workaround for this - we allow failing tests to be retried up to 3 times to make them pass. If they still fail, we will consider them as flaky tests and have to fix them moving forward.

This PR also address minor comments and fixes a test.

Instrument ConfigAccessor's constructors (#856)

This diff instruments ConfigAccessor's constructors to make it realm-aware. If ConfigAccessor is unable to start on multi-realm mode, then it falls back to starting on single-realm mode.

Make RealmAwareZkClient implementations use HttpRoutingDataReader for routing data (#819)

We want all implementations of RealmAwareZkClient to do a one-time query to Metadata Store Directory Service for routing data and cache it in memory. In order to accomplish that, we have introduced HttpRoutingDataReader, which is a Singleton class that makes a REST call to read routing data and caches it in memory. This diff updates the initialization logic in RealmAwareZkClients accordingly.

Changelist:
1. Update all RealmAwareZkClient initialization logic
2. Fix tests

Implement setRoutingData for MetadataStoreDirectoryService (#844)

Implement setRoutingData endpoint. Modify TrieRoutingData construction in MetadataStoreDirectory. Fix race conditions among writing operations in MetadataStoreDirectory.

Make ConfigAccessor and ZkUtil realm-aware (#838)

To make Helix Java APIs realm-aware, we first make ConfigAccessor and ZkUtil realm-aware by instrumenting these APIs with a Builder and RealmAwareZkClients.

The Builder pattern is chosen because it is a scalable option when there are a lot of configurable parameters. It makes it easy to validate the given parameters as well.

Add FederatedZkClient (#789)

As part of ZkClient API enhancement, we wish to add FederatedZkClient, which is a wrapper of the raw ZkClient, that provides realm-aware access to ZooKeeper.
FederatedZkClient will internally maintain multiple ZooKeeper sessions connecting to different ZooKeeper realms on an as-needed basis and route requests to the appropriate ZooKeeper based on the ZK path sharding key. Ephemeral node creation is not supported.

Make MSDS endpoint configurable for HttpRoutingDataReader (#836)

We need to add a few more constructors that allows the users to configure which MSDS to talk to. Applications may wish to create RealmAwareZkClients connecting to different regions or namespaces.

Improve MetadataStoreDirectoryAccessor endpoints and fix bugs in ZkRoutingDataReader/Writer

Improve the current status code design of MetadataStoreDirectoryAccessor endpoints by more clearly translate underlying exceptions to status codes. Fix 4 bugs in Reader/Writer.

Add SharedZkClient/InnerSharedZkClient implementation (#796)

Refactor the original SharedZkClient to InnerSharedZkClient. Add
SharedZkClient implementation. The implementation use composition
pattern. It would check the ZkPath validity and delegate the
implementation to InnerSharedZkClient. In sum, InnerSharedZkClient
is shared ZkClient but not realm aware. SharedZkClient is truely
realm aware ZkClient.

Update bump-up.command and ivy imports (#824)

We update the bump-up.command script here so that it includes newly added modules.
.ivy change was needed for wrapper repositories could pick up on the right open-source libraries.

Fix InvalidRoutingData error message in tests (#821)

This PR aims to fix the InvalidRoutingDataException error message that shows up in tests. The source of this error was due to two test cases in TestZkMetadataStoreDirectory, in which both of the test cases inserted "/a/b/c/d/e" directly into the same set of routing data. This renders the routing data invalid because one sharding key is pointing to two realms.
This was not caught at insertion because the insertion was done directly instead of through a dedicated API (because the code in question is a test case). The tests didn't fail because they relied on the raw routing data for correctness. The construction of MetadataStoreRoutingData failed "correctly" as can be seen from the error messages, however the construction failure was after raw routing data being fetched, therefore making the situation undetected.

Implement request forwarding for ZkRoutingDataWriter (#788)

This PR added the request forwarding feature to ZkRoutingDataWriter. It also included a lot of other work, most notably: changing ZkMetadataStoreDirectory to singleton in order to allow leader forwarding, added integration tests for the request forwarding flow, modified MetadataStoreDirectoryAccessor for it to respect underlying return values, fixed numerous behavior bugs.

Add getShardingKeyInPath to MetadataStoreRoutingData (#817)

Add getShardingKeyInPath to MetadataStoreRoutingData

Add HttpRoutingDataReader (#775)

HttpRoutingDataReader is a component used by new ZkClient APIs to make an HTTP read request to the metadata store directory service to retrieve routing data. ZkClient APIs will construct an internal MetadataStoreRoutingData instance based on the raw routing data retrieved from MSDS.

Note: this change contains modifications to MockMSDS because the actual endpoint names changed. The methods and http server contexts have been updated.

[helix-rest] Add endpoint to get namespace routing data (#799)

RealmAwareZkClient construction needs a REST endpoint to get routing data in a namespace. This endpoint will help with reducing REST calls down to one single call to read all raw routing data in ZK.

This commit adds Java API getNamespaceRoutingData() and an endpoint "GET /routing-data".

Add REST read endpoints to helix-rest for metadata store directory (#761)

We need restful metadata store directory service to help scale out zookeeper.

This commit adds REST read endpoints to helix-rest to get sharding keys, realms and namespaces.

Add DedicatedZkClient and update DedicatedZkClientFactory (#765)

As part of ZkClient API enhancement, we wish to add DedicatedZkClient, which is a wrapper of the raw ZkClient, that provides realm-aware access to ZooKeeper.

Realm-aware in that it only performs requests whose path's Zk path sharding key belongs to the ZK realm it's connected to.

Also, we need to modify DedicatedZkClientFactory so that users could use this factory to generate instances of DedicatedZkClient.