New Modules for Apache Helix

Overview

This page explains what kind of new modules will be added and which modules will be affected.

Why?

The helix-core module has evolved and has become a hodgepodge of all Helix's core classes. The biggest motivation comes from the initiative to separate all metadata-related functionalities (ZooKeeper for example) into a separate module.

Perceived benefits include

• Monitoring (DynamicMBean in Helix's ZkClient)
• Access control (on roadmap)
• Separating modules also decouples helix-core from ZooKeeper APIs. What this means is that we could have separate deployment cadences and isolate problems better.
• Another perceived benefit is that we could remove the import of the IOItec ZK library - it is known to have a few bugs (which have been fixed in Helix's ZkClient) and have backward-compatibility issues.

New Structure

• metrics-common A module that contains all MBean-related metric classes.

• helix-common All classes that are common to Helix-related classes (such as ZNRecord, HelixException, etc.) will be moved to helix-common.

• zookeeper-api ZkClient and the supporting classes thereof will all be placed in zookeeper-api.

Existing Modules

Existing modules will get an update to the library imports in their respective pom.xml. Instead of just importing helix-core, the existing modules will import both helix-core and zookeeper-api.

Migration Guide for Helix Applications

1. All the classes in helix-common kept the same package structure they had in helix-core, so there should be no code change required.
2. For ZK-related classes, most of them are backported by way of subclassing. But if you used IOItec classes explicitly, you'll need to fix the imports (because we no longer import IOItec!). Do the following:

Find-replace in your project:

• org.I0Itec -> org.apache.helix.zookeeper.api E.g.) import org.I0Itec.zkclient.ZkServer; becomes import org.apache.helix.zookeeper.api.zkclient.ZkServer;

3. If you use I0Itec's ZkClient directly in your project, you'll want to change those to using HelixZkClient via the static factories provided. There are two types of factories Helix provides:
4. SharedZkClientFactory - one shared ZkClient that has multiple ZkConnections inside it. Use for CRUD operations.
5. DedicatedZkClientFactory - one ZkClient with one ZkConnection. The behavior of this is same as if you used a raw ZkClient.

See the example below:

ZkClient client = new ZkClient("localhost:2191", 10000, 10000, new ZNRecordSerializer());

becomes

HelixZkClient.ZkConnectionConfig zkConnectionConfig = new HelixZkClient.ZkConnectionConfig("localhost:2191").setSessionTimeout(10000); HelixZkClient client = DedicatedZkClientFactory.getInstance().buildZkClient(zkConnectionConfig, new HelixZkClient.ZkClientConfig().setZkSerializer(new ZNRecordSerializer()));

Note that HelixZkClient is a fully-compatible interface with I0Itec's ZkClient.

Migration Guide for General ZooKeeper Clients

If your use case does not require client-side sharding/routing (ZooScalability), then you can simply use the ZkClient implementation with a Builder in the following package:

org.apache.helix.zookeeper.impl.client.ZkClient

If you wish to take advantage of ZooScalability, we have other implementations of ZkClient with varying degrees of abstraction that incorporates client-side routing. These ZkClient implementations follow the interface org.apache.helix.zookeeper.api.client.RealmAwareZkClient.java.