[
https://issues.apache.org/jira/browse/HADOOP-6760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867342#action_12867342
]
Konstantin Boudnik commented on HADOOP-6760:
--------------------------------------------
Aftere some considerations and investigations we have found that the workaround
from HADOOP-6386 has a very unpleasant side effect which weren't apparent at
the time. Here what is happening:
- daemons like NN, TT, etc. are adding certain context to the webserver before
it is started,
- when the workaround in question detects a negative port problem (aka Jetty
race) it applies some logic which essentially restarts the server via
{{server.stop()}} and {{server.start()}} calls.
- the trick is that {{server.stop()}} clears up (or either shutdown) all
previously added context.
The effect of this is that even a daemon's webserver was started it lacks all
intimate little servlets which were added initially. Thus a daemon's webserver
becomes pretty much useless.
Unfortunately, there's no easy way to fix it because the context is being added
outside and it'd be pretty tricky to trace what context needs to be preserved
before server is restarted and so on.
I believe the better solution would be to revert the workaround introduced by
HADOOP-6386. In that case we'll get back to the original behavior where
webserver either starts or fails but isn't left in an inconsistent state.
> 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.
