No response when connecting client to dask-scheduler

[Kyeongpil]

I ran dask scheduler as dask-scheduler --scheduler-file /users/ddd/workspace/fff/tmp/scheduler.json and scheduler.json was created file in that directory

and here are contents of scheduler.json:
{
"type": "Scheduler",
"id": "Scheduler-695028c5-521c-455b-a4f7-a84dcbc35c8e",
"address": "tcp://***:8786",
"services": {
"bokeh": 8787
},
...
}

also, dask-worker --scheduler-file /users/ddd/workspace/fff/tmp/scheduler.json

I try to connect client to dask scheduler in network file system using below code:
client = Client(scheduler_file='/users/ddd/workspace/fff/tmp/scheduler.json')

but it doesn't work (no any response or it may be in infinite loop).

I think client can't connect to dask-scheduler. However, I don't know how to solve this problem...

How can I solve this problem? Is there anyone who had similar problem?

[mrocklin]

To help diagnose your problem I recommend including logs from your scheduler, workers, and client.

[Kyeongpil]

@mrocklin

I capture logs of scheduler and worker as below.

and scheduler.json

and then I got these errors

Do you know why I got these errors? :(

[Kyeongpil]

I'm currently using
dask==0.17.1
distributed==1.21.3
tornado==5.0
python 3.6.4

[mrocklin]

No, I don't know. The two most common causes of this kind of issue are: 1. You have different versions of Python/Dask/... running on the different machines (this is worth double-checking even if you are confident) 2. Your computers are not accessible to each other with that address. For example machines might have one network that they use for communication within the network and another machine that they use for communication with outside machines. To see if this is an issue you might try standing up simpler services, like HTTP servers with `python -m http.server` and seeing if you can connect with the expected address.

…

On Wed, Mar 14, 2018 at 12:38 PM, Kyeongpil Kang ***@***.***> wrote: I'm currently using dask==0.17.1 distributed==1.21.3 tornado==5.0 python 3.6.4 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1837 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszCgNyCSFrkcccc3t8HexOOVDGppQks5teUdxgaJpZM4Sp7Y8> .

[Kyeongpil]

@mrocklin

1. I have same anaconda environment because I'm using shared network file system
2. Although address of worker and one of scheduler is different, I find that worker registered to scheduler.
   Therefore, I think computers on different network can communicate each other...

[Kyeongpil]

Oh, I solved this problem
When I connecting to client, I used asynchronous option like:
client = Client(scheduler_file="~~~", asynchronous=True)

After removing asynchronous=True, it worked!
I guess tornado can't connect other network.

[mrocklin]

You should only use asynchronous=True when using the Client in coroutines like the following:

async def f():
    client = await Client(..., asynchronous=True)

This tends to be rare among new users. I'm curious, why did you select asynchronous=True? What did you expect from setting that keyword argument? I'm wondering how we can improve documentation or docstrings to avoid this sort of situation in the future.

[Kyeongpil]

I was intended to get workers' results asynchronously.

Actually, when I run scheduler and workers and client in single server with asynchronous=True option,
it worked well.

[mrocklin]

I've addressed this with a docstring fix here: #1842