Github user srowen commented on a diff in the pull request:

    https://github.com/apache/spark/pull/2623#discussion_r18334033
  
    --- Diff: core/src/main/scala/org/apache/spark/util/Utils.scala ---
    @@ -1437,7 +1437,13 @@ private[spark] object Utils extends Logging {
         val serviceString = if (serviceName.isEmpty) "" else s" '$serviceName'"
         for (offset <- 0 to maxRetries) {
           // Do not increment port if startPort is 0, which is treated as a 
special port
    -      val tryPort = if (startPort == 0) startPort else (startPort + 
offset) % 65536
    +      val _tryPort = if (startPort == 0) startPort else (startPort + 
offset) % 65536
    --- End diff --
    
    The formulas differ at least whenever `startPort + offset >= 65536`. For 
example, try port 65526 and offsets 10, 11, 12 ...  We need it to return 1024, 
1025, 1026, not 0, 1, 2.
    
    I don't think the question here is whether ports under 1024 should be 
usable in Spark. I think they should be, if that's what the caller wants. Yes, 
it will fail if the user does not run with root privileges, but that's to be 
expected.
    
    (There's an argument here that failing to bind to a specified, privileged 
port should just be an error. That is, if I ask for port 80, it's probably not 
right to try 81, 82, ... because those can be canonical ports for other types 
of service.)
    
    The problem here is requesting a _non-privileged_ port like 65535, but then 
finding that Spark starts trying _privileged_ ports. That doesn't seem OK. I 
think just adding `- 1024` to your original patch makes it work.
    
    Separately then, is there support for failing if a privileged port is 
requested and is not available, rather than trying other ports?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to