Check if port is in use (before trying to publish the dashboard to it)

[jakirkham]

Recently had the awkward experience of connecting to someone else's Dask Distributed instance (their Dashboard in particular) by accident as they were using the same node and port as I was trying to use. To help prevent this, it would be useful if Distributed (optionally) protected itself against this a bit by checking if a port is already in use and either failing with a traceback or attempt to connect with the next available port (e.g. 8787 to 8788 for example) of course this means a few other ports would need to be bumped in the process. FWIW the latter (bumping port number) is what the Jupyter Notebook does with this problem. So there might be some tips to be learned from looking in the Jupyter Notebook code base. There may be other ways to solve this that I haven't thought of. So please feel free to share.

Side note: Can also see how this might be a useful feature. So other options might include warning or an option to always starting a new scheduler with new services.

[mrocklin]

I think that the current behavior is to try 8787 and, if it is taken, switch to 0 (random port). This port is displayed wherever we display the link. We could also err explicitly if the port is specified explicitly (--bokeh-port 8787) and taken

…

On Thu, Apr 19, 2018 at 10:52 AM, jakirkham ***@***.***> wrote: Recently had the awkward experience of connecting to someone else's Dask Distributed instance (their Dashboard in particular) by accident as they were using the same node and port as I was trying to use. To help prevent this, it would be useful if Distributed (optionally) protected itself against this a bit by checking if a port is already in use and either failing with a traceback or attempt to connect with the next available port (e.g. 8787 to 8788 for example) of course this means a few other ports would need to be bumped in the process. FWIW the latter (bumping port number) is what the Jupyter Notebook does with this problem. So there might be some tips to be learned from looking in the Jupyter Notebook code base. There may be other ways to solve this that I haven't thought of. So please feel free to share. Side note: Can also see how this might be a useful feature. So other options might include warning or an option to always starting a new scheduler with new services. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1926>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszP097DZNZgpXvHJVn7hplnLrrOHiks5tqKSVgaJpZM4Tb8dv> .

[jakirkham]

Thanks for the info. Where is the code for this?

[mrocklin]

distributed/bokeh/core.py::BokehServer.listen

…

On Thu, Apr 19, 2018 at 11:06 AM, jakirkham ***@***.***> wrote: Thanks for the info. Where is the code for this? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1926 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszEcbasOYNcVFXXKkn2z_ruztFxOZks5tqKgCgaJpZM4Tb8dv> .

[mrocklin]

@jakirkham where does this stand? Is there anything that needs to be done here?

[jakirkham]

Basically the current behavior is not what I would expect and it didn’t match the description you’ve provided. Distributed happily suggested using the Dashboard from my coworker’s instance. It was pretty obvious to me what was going on, but can see how this would quickly become a problem if lots of users started spinning up their own instances on the cluster.