Return-Path: <notifications-return-35840-archive-asf-public=cust-asf.ponee.io@accumulo.apache.org>
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 0F6B5200B27
	for <archive-asf-public-internal@cust-asf2.ponee.io>; Wed,  8 Jun 2016 01:20:23 +0200 (CEST)
Received: by cust-asf.ponee.io (Postfix)
	id 0DE82160A36; Tue,  7 Jun 2016 23:20:23 +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 5FA80160A57
	for <archive-asf-public@cust-asf.ponee.io>; Wed,  8 Jun 2016 01:20:22 +0200 (CEST)
Received: (qmail 8078 invoked by uid 500); 7 Jun 2016 23:20:21 -0000
Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:notifications-help@accumulo.apache.org>
List-Unsubscribe: <mailto:notifications-unsubscribe@accumulo.apache.org>
List-Post: <mailto:notifications@accumulo.apache.org>
List-Id: <notifications.accumulo.apache.org>
Reply-To: jira@apache.org
Delivered-To: mailing list notifications@accumulo.apache.org
Received: (qmail 7907 invoked by uid 99); 7 Jun 2016 23:20:21 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Jun 2016 23:20:21 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id 187AF2C1F6C
	for <notifications@accumulo.apache.org>; Tue,  7 Jun 2016 23:20:21 +0000 (UTC)
Date: Tue, 7 Jun 2016 23:20:21 +0000 (UTC)
From: "Dave Marion (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12976447.1465306852000.21506.1465341621097@Atlassian.JIRA>
In-Reply-To: <JIRA.12976447.1465306852000@Atlassian.JIRA>
References: <JIRA.12976447.1465306852000@Atlassian.JIRA> <JIRA.12976447.1465306852295@arcas>
Subject: [jira] [Commented] (ACCUMULO-4331) Make port configuration and
 allocation consistent across services
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
archived-at: Tue, 07 Jun 2016 23:20:23 -0000


    [ https://issues.apache.org/jira/browse/ACCUMULO-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319673#comment-15319673 ] 

Dave Marion commented on ACCUMULO-4331:
---------------------------------------

I was not thinking of doing anything with port search, other than making it use a 1up algorithm instead of random. I was thinking of allowing a single port (N or zero) or a range or ports (N-M) to be allowed in the port properties mentioned in the description. For example:
{noformat}
<property>
  <name>tserver.port.client</name>
  <value>9997</value>
</property>
{noformat}

or

{noformat}
<property>
  <name>tserver.port.client</name>
  <value>0</value>
</property>
{noformat}

or 

{noformat}
<property>
  <name>tserver.port.client</name>
  <value>9997-9999</value>
</property>
{noformat}

> Make port configuration and allocation consistent across services
> -----------------------------------------------------------------
>
>                 Key: ACCUMULO-4331
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-4331
>             Project: Accumulo
>          Issue Type: Bug
>    Affects Versions: 1.8.0
>            Reporter: Dave Marion
>             Fix For: 1.8.0
>
>
> There was some discussion in ACCUMULO-4328 about ports, so I decided to track down how the client ports are configured and allocated. Issues raised in the discussion were:
>  1. The port search feature was not well understood
>  2. Ephemeral port allocation makes it hard to lock servers down (e.g. iptables)
> Looking through the code I found the following properties allocate a port number based on conf.getPort(). This returns the port number based on the property and supports either a single value or zero. Then, in the server component (monitor, tracer, gc, etc) this value is used when creating a ServerSocket. If the port is already in use, the process will fail.
> {noformat}
> monitor.port.log4j
> trace.port.client
> gc.port.client
> monitor.port.client
> {noformat}
> The following properties use TServerUtils.startServer which uses the value in the property to start the TServer. If the value is zero, then it picks a random port between 1024 and 65535. If tserver.port.search is enabled, then it will try a thousand times to bind to a random port.
> {noformat}
> tserver.port.client
> master.port.client
> master.replication.coordinator.port
> replication.receipt.service.port
> {noformat}
> I'm proposing that we deprecate the tserver.port.search property and the value zero in the property value for the properties above. Instead, I think we should allow the user to specify a single value or a range (M-N). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)