Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 90CE1200D50 for ; Mon, 4 Dec 2017 20:42:52 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 8F48D160BF9; Mon, 4 Dec 2017 19:42:52 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id D5E79160BF7 for ; Mon, 4 Dec 2017 20:42:51 +0100 (CET) Received: (qmail 43922 invoked by uid 500); 4 Dec 2017 19:42:50 -0000 Mailing-List: contact user-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@ignite.apache.org Delivered-To: mailing list user@ignite.apache.org Received: (qmail 43912 invoked by uid 99); 4 Dec 2017 19:42:50 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Dec 2017 19:42:50 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 2C1FB1A1574 for ; Mon, 4 Dec 2017 19:42:50 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.172 X-Spam-Level: ** X-Spam-Status: No, score=2.172 tagged_above=-999 required=6.31 tests=[DKIM_ADSP_CUSTOM_MED=0.001, NML_ADSP_CUSTOM_MED=1.2, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.972] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id DvD9qdAptXdY for ; Mon, 4 Dec 2017 19:42:49 +0000 (UTC) Received: from n6.nabble.com (n6.nabble.com [162.255.23.37]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id ECD5D5FB4A for ; Mon, 4 Dec 2017 19:42:48 +0000 (UTC) Received: from n6.nabble.com (localhost [127.0.0.1]) by n6.nabble.com (Postfix) with ESMTP id F203A3457CAD for ; Mon, 4 Dec 2017 12:42:47 -0700 (MST) Date: Mon, 4 Dec 2017 12:42:47 -0700 (MST) From: Chris Berry To: user@ignite.apache.org Message-ID: <1512416567989-0.post@n6.nabble.com> In-Reply-To: References: <1512369278083-0.post@n6.nabble.com> Subject: Re: ignite.compute(ClusterGroup) is broken?? MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable archived-at: Mon, 04 Dec 2017 19:42:52 -0000 Hi Denis,=20 Thank you for responding. >>> Can you provide a short summary of what you are trying to achieve? The problem is this. Ignite begins sending compute traffic to a Node (i.e. ComputeJobs), before that Node is truly ready to take traffic. Basically, as soon as Ignite starts and is balanced on a Node, it begins receiving compute traffic. This is wrong.=20 It means that as a Node starts up, it is slammed with traffic it is not ready to handle yet. So. We must reject that traffic until we are ready (throw an Exception). Which, then, fails that ComputeJob over to another Node. This, of course, works. But it is costly, in terms of system throughput as Nodes come and go in AWS. We need the ability to notify a Node that it is ready to handle compute load. Instead of Ignite *assuming* that the Node is ready as soon as Ignite is started. It is a classic chicken-and-egg problem. We need Ignite started and rebalanced, because we need to interact w/ some Ignite caches. Thus, we need to start Ignite before we can finish enabling the app. In addition, many other things at startup things happen in the background, such as Kafka streaming in data to some caches, etc. And when all of this is complete, we toggle an =E2=80=9CAlive switch=E2=80= =9D that indicates that the Node is ready for business. >>> The main thing that I don't understand is why you need a=C2=A0map=C2=A0= method? >>> This method is supposed to be used as a part of a map-reduce pipeline. >>> It is aimed to split one big task into many small jobs. This is exactly how we are using it. But the question at hand here is about whether; ignite.cluster.compute(ClusterGroup) is broken or not. Because my logs clearly show me that even though I am absolutely certain that a ClusterGroup, passed to the compute() method, does NOT contain a particular Node. I can see that Node receiving ComputeJobs. I do not see how that can be possible. Thanks,=20 -- Chris=20 -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/