[
https://issues.apache.org/jira/browse/ACCUMULO-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318909#comment-15318909
]
Michael Wall commented on ACCUMULO-4331:
----------------------------------------
It would be really useful if we are going to run multiple tservers on a node to
be able to set static ports. So if I want to run 3 on a node, I can configure
them to always run on 9997, 9998 and 9999 or whatever. That is useful from a
system monitoring perspective. Also useful because in the tserver page in the
monitor, when a tserver dies and comes back up on the same port, it would be
removed from the list of dead tservers. I find it useful to follow restarts of
a tserver in one log file as well, although I think [~dlmarion] has that
working already. Would love to see the port as part of the log4j filename as
well, so you know automatically which log file to open instead of having to
grep for something in all the log files.
> 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)
