[
https://issues.apache.org/jira/browse/HELIX-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14113972#comment-14113972
]
ASF GitHub Bot commented on HELIX-470:
--------------------------------------
Github user hsaputra commented on a diff in the pull request:
https://github.com/apache/helix/pull/2#discussion_r16853182
--- Diff: helix-ipc/NOTICE ---
@@ -0,0 +1,33 @@
+Apache Helix
--- End diff --
Forgot to comment this one. Please move NOTICE file content to NOTICE in
top level Helix directory. Then you can remove this one.
NOTICE file should be bundled into one when making releases and just copy
this to main NOTICE will make packaging easier.
> Add performant IPC (Helix actors)
> ---------------------------------
>
> Key: HELIX-470
> URL: https://issues.apache.org/jira/browse/HELIX-470
> Project: Apache Helix
> Issue Type: Improvement
> Components: helix-core
> Affects Versions: 0.7.1, 0.6.4
> Reporter: Greg Brandt
>
> Helix is missing a high-performance way to exchange messages among resource
> partitions, with a user-friendly API.
> Currently, the Helix messaging service relies on creating many nodes in
> ZooKeeper, which can lead to ZooKeeper outages if messages are sent too
> frequently.
> In order to avoid this, high-performance NIO-based {{HelixActors}} should be
> implemented (in rough accordance with the actor model). {{HelixActors}}
> exchange messages asynchronously without waiting for a response, and are
> partition/state-addressable.
> The API would look something like this:
> {code}
> public interface HelixActor<T> {
> void send(Partition partition, String state, T message);
> void register(String resource, HelixActorCallback<T> callback);
> }
> public interface HelixActorCallback<T> {
> void onMessage(Partition partition, State state, T message);
> }
> {code}
> {{#send}} should likely support wildcards for partition number and state, or
> its method signature might need to be massaged a little bit for more
> flexibility. But that's the basic idea.
> Nothing is inferred about the format of the messages - the only metadata we
> need to be able to interpret is (1) partition name and (2) state. The user
> provides a codec to encode / decode messages, so it's nicer to implement
> {{HelixActor#send}} and {{HelixActorCallback#onMessage}}.
> {code}
> public interface HelixActorMessageCodec<T> {
> byte[] encode(T message);
> T decode(byte[] message);
> }
> {code}
> Actors should support somewhere around 100k to 1M messages per second. The
> Netty framework is a potential implementation candidate, but should be
> thoroughly evaluated w.r.t. performance.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
