[
https://issues.apache.org/jira/browse/HADOOP-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866304#action_12866304
]
Eli Collins commented on HADOOP-6760:
-------------------------------------
Hey Kos - your patch looks correct to me. Rationale being that according to
the jetty javadoc below getPort should never return a negative value, therefore
oriPort should never be negative, therefore you don't need the workaround of
adding one, and it's OK to re-bind to the same port.
Not your change but the "workaround HADOOP-4744" looks ok, per the docs below
it is valid for getLocalPort to return -1, but I think it could be simpler,
something like the following. Make sense?
{code}
int numRetries = 1;
while (port < 0) {
LOG.warn("listener.getLocalPort returned " + port);
if (numRetries++ > MAX_RETRIES) {
throw new Exception(" listener.getLocalPort is returning " +
"less than 0 even after " +numRetries+" resets");
}
LOG.info("Bouncing the listener");
listener.close();
Thread.sleep(1000);
listener.setPort(oriPort);
listener.open();
Thread.sleep(100);
port = listener.getLocalPort();
}
{code}
187 /**
188 * @return The configured port for the connector or 0 if any available
189 * port may be used.
190 */
191 int getPort();
192
193 /* ------------------------------------------------------------ */
194 /**
195 * @return The actual port the connector is listening on or -1 if there
196 * is no port or the connector is not open.
197 */
198 int getLocalPort();
{code}
> WebServer shouldn't increase port number in case of negative port setting
> caused by Jetty's race
> ------------------------------------------------------------------------------------------------
>
> Key: HADOOP-6760
> URL: https://issues.apache.org/jira/browse/HADOOP-6760
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 0.20.3
> Reporter: Konstantin Boudnik
> Assignee: Konstantin Boudnik
> Attachments: HADOOP-6760.0.20.patch, HADOOP-6760.patch
>
>
> When a negative port is assigned to a webserver socket (because of a race
> inside of the Jetty server) the workaround from HADOOP-6386 is increasing the
> original port number on the next bind attempt. Apparently, this is an
> incorrect logic and next bind attempt should happen on the same port number
> if possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.