Provide the timeout value in useful places #2436
Conversation
EnricoMi
force-pushed
the
branch-verbose-timeout
branch
from
d649be1
to
a3e7574
Compare
This comment has been minimized.
This comment has been minimized.
EnricoMi
force-pushed
the
branch-verbose-timeout
branch
from
a3e7574
to
446a72d
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
- Also adds spark_require_list to dev_require_list so that: pip install -e .[dev] also installs spark packages. - Further sets h5py<3 in spark_require_list. Signed-off-by: Enrico Minack <github@enrico.minack.dev>
| @@ -49,8 +49,9 @@ void HTTPStore::wait(const std::vector<std::string>& keys, | |||
| const auto elapsed = std::chrono::duration_cast<std::chrono::seconds>( | |||
| std::chrono::steady_clock::now() - start); | |||
| if (timeout != gloo::kNoTimeout && elapsed > timeout) { | |||
| GLOO_THROW_IO_EXCEPTION(GLOO_ERROR_MSG("Wait timeout for key(s): ", | |||
| ::gloo::MakeString(keys))); | |||
| auto timeout_seconds = std::chrono::duration_cast<std::chrono::seconds>(timeout); | |||
There was a problem hiding this comment.
Nice! Can you also add a suggestion here to try increasing HOROVOD_GLOO_TIMEOUT_SECONDS?
There was a problem hiding this comment.
Ideally, that should be in the exception message, but this part of the code does not know (and should not make this assumption) where the timeout value is coming from, it is just an argument to this method. The env var is defined and read in gloo_context.cc.
Ideally, the timeout exception should be caught there and re-thrown with an enhanced message saying where to set the timeout. For that, the exception must be of a very specific type, like gloo timeout exception for that to work.
My hope is seeing the timeout at all in the logs helps to realize that whatever timeout knob you used is the wrong one. Not ideal but better than nothing.
Any better idea?
There was a problem hiding this comment.
We could move the reading of HOROVOD_GLOO_TIMEOUT_SECONDS into this class. It's never set to anything else in practice.
There was a problem hiding this comment.
There is no gloo:TimeoutException, that would have been too good... Then I would rather add the env var to the error message, though it is bad practise, but moving the env var in this code would be worse I think.
There was a problem hiding this comment.
I think having the env variable in the error is very useful. Otherwise users will not know how to resolve the issue, and will ask questions on GitHub that could be answered by the error message (this has happened a few times). I agree it's making an assumption that isn't guaranteed by the interface, but I think it's worth it. What do you think?
There was a problem hiding this comment.
Yes, the information is more useful for users than clean code separation for developers in this case, I will go for it.
There was a problem hiding this comment.
I had to move the constants into gloo_context.h: 6cd9213
EnricoMi
force-pushed
the
branch-verbose-timeout
branch
from
a6881cc
to
1470403
Compare
This comment has been minimized.
This comment has been minimized.
Signed-off-by: Enrico Minack <github@enrico.minack.dev>
EnricoMi
force-pushed
the
branch-verbose-timeout
branch
from
fcfeb75
to
6cd9213
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Unit Test Results 522 files - 13 522 suites - 13 4h 27m 12s ⏱️ - 3m 0s For more details on these failures, see this check. Results for commit 6cd9213. ± Comparison against base commit 108d3a6. |
Providing the timeout value in logging and exceptions helps to identify which timeout is actually being used and causes the exception.
Also adds
spark_require_listtodev_require_listso thatpip install -e .[dev]also installs spark packages.Further sets
h5py<3inspark_require_list.Improves resolving issues like #2419.