Return-Path: X-Original-To: apmail-giraph-user-archive@www.apache.org Delivered-To: apmail-giraph-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3520110078 for ; Fri, 22 Nov 2013 17:15:52 +0000 (UTC) Received: (qmail 72150 invoked by uid 500); 22 Nov 2013 17:15:49 -0000 Delivered-To: apmail-giraph-user-archive@giraph.apache.org Received: (qmail 72034 invoked by uid 500); 22 Nov 2013 17:15:43 -0000 Mailing-List: contact user-help@giraph.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@giraph.apache.org Delivered-To: mailing list user@giraph.apache.org Received: (qmail 72026 invoked by uid 99); 22 Nov 2013 17:15:41 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Nov 2013 17:15:41 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lawrence.compton@gmail.com designates 74.125.82.174 as permitted sender) Received: from [74.125.82.174] (HELO mail-we0-f174.google.com) (74.125.82.174) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Nov 2013 17:15:36 +0000 Received: by mail-we0-f174.google.com with SMTP id q58so1415709wes.19 for ; Fri, 22 Nov 2013 09:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3J8uqGZ8Msvtuu2Adl3DByDll/iNsyX04shn+ywhXp0=; b=j03mP6P9F3687P9ZgiFRCIi2FMGzS+qZLzJlyrZLDtCHB5f7ax2Hs1Rx0RUEp9CFKJ IlkyY6JR8NSCjH/Kxw+Rv4n2dJZhfxy1dgx+CmHybxPSeLVt6NnpSqJGJmk+NfyawCLI 2DUPK54Tf4RS49vKxFIRfqT8TAoW+1QnVf6ej2AjfHp/ZgsWclomDFX0EbIUSsNVRDRZ FqC4mfnMqXYzP1BoLfHHAvRRJ0J5tvDi3Q8WG1n5huP0phScsw7dTcQrpA+Bxki1bubv tS+FTVJTnRePa5qGDWOGSMjq6+i7o5hJHzPXa5GPYKgIDO05iK6wAvjP9gu77weDZwH+ HEKQ== MIME-Version: 1.0 X-Received: by 10.194.57.243 with SMTP id l19mr2594035wjq.54.1385140514964; Fri, 22 Nov 2013 09:15:14 -0800 (PST) Received: by 10.180.188.37 with HTTP; Fri, 22 Nov 2013 09:15:14 -0800 (PST) Date: Fri, 22 Nov 2013 12:15:14 -0500 Message-ID: Subject: Giraph 1.0.0 - Netty port allocation From: Larry Compton To: user@giraph.apache.org Content-Type: multipart/alternative; boundary=047d7b8736a05bcbb104ebc7283d X-Virus-Checked: Checked by ClamAV on apache.org --047d7b8736a05bcbb104ebc7283d Content-Type: text/plain; charset=ISO-8859-1 My teammates and I are running Giraph on a cluster where a firewall is configured on each compute node. We had 100 ports opened on the compute nodes, which we thought would be more than enough to accommodate a large number of workers. However, we're unable to go beyond about 90 workers with our Giraph jobs, due to Netty ports being allocated outside of the range (30000-30100). We're not sure why this is happening. We shouldn't be running more than one worker per compute node, so we were assuming that only port 30000 would be used, but we're routinely seeing Giraph try to use ports greater than 30100 when we request close to 100 workers. This leads us to believe that a simple one up numbering scheme is being used that doesn't take the host into consideration, although this is only speculation. Is there a way around this problem? Our system admins understandably balked at opening 1000 ports. Larry --047d7b8736a05bcbb104ebc7283d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My teammates and I are running Giraph on a cluster wh= ere a firewall is configured on each compute node. We had 100 ports opened = on the compute nodes, which we thought would be more than enough to accommo= date a large number of workers. However, we're unable to go beyond abou= t 90 workers with our Giraph jobs, due to Netty ports being allocated outsi= de of the range (30000-30100). We're not sure why this is happening. We= shouldn't be running more than one worker per compute node, so we were= assuming that only port 30000 would be used, but we're routinely seein= g Giraph try to use ports greater than 30100 when we request close to 100 w= orkers. This leads us to believe that a simple one up numbering scheme is b= eing used that doesn't take the host into consideration, although this = is only speculation.

Is there a way around this problem? Our system admins unders= tandably balked at opening 1000 ports.

Larry
--047d7b8736a05bcbb104ebc7283d--