[ https://issues.apache.org/jira/browse/ACCUMULO-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15320801#comment-15320801 ]
Keith Turner commented on ACCUMULO-4331: ---------------------------------------- I like the idea of using that notation. I looked around and did not find any thing in Guava to parse it. Did find some simeple code to do it on stackoverflow. Could use this code and a Guava Range. http://stackoverflow.com/questions/33552639/parsing-interval-notation-to-guava-range > 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 > Assignee: 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)