Return-Path: X-Original-To: apmail-helix-commits-archive@minotaur.apache.org Delivered-To: apmail-helix-commits-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7E6BB1132F for ; Thu, 28 Aug 2014 21:29:35 +0000 (UTC) Received: (qmail 90092 invoked by uid 500); 28 Aug 2014 21:29:35 -0000 Delivered-To: apmail-helix-commits-archive@helix.apache.org Received: (qmail 90057 invoked by uid 500); 28 Aug 2014 21:29:35 -0000 Mailing-List: contact commits-help@helix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@helix.apache.org Delivered-To: mailing list commits@helix.apache.org Received: (qmail 90048 invoked by uid 99); 28 Aug 2014 21:29:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Aug 2014 21:29:35 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.3] (HELO mail.apache.org) (140.211.11.3) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 28 Aug 2014 21:29:29 +0000 Received: (qmail 87941 invoked by uid 99); 28 Aug 2014 21:29:09 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Aug 2014 21:29:09 +0000 Date: Thu, 28 Aug 2014 21:29:09 +0000 (UTC) From: "Hudson (JIRA)" To: commits@helix.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HELIX-470) Add performant IPC (Helix actors) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HELIX-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14114378#comment-14114378 ] Hudson commented on HELIX-470: ------------------------------ SUCCESS: Integrated in helix #1288 (See [https://builds.apache.org/job/helix/1288/]) [HELIX-470] Netty-based IPC layer, add TestNG config (kbiscuitwala: rev 2a671a116db8f02de4d2208e03241d62935b9fc2) * helix-ipc/src/test/conf/testng.xml > 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 > Fix For: 0.7.1 > > > 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 { > void send(Partition partition, String state, T message); > void register(String resource, HelixActorCallback callback); > } > public interface HelixActorCallback { > 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 { > 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)