-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[serve] Implement timeouts for streaming & enable all tests with experimental streaming flag turned on #36261
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, this change looks good to me overall!
else: | ||
curr_timeout_s = timeout_s - (time.time() - start) | ||
|
||
obj_ref = await obj_ref_generator._next_async(timeout_s=curr_timeout_s) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's obj_ref_generator
's behavior if the timeout is negative? What if it's zero?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question, let me check and ensure we're being defensive here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
zero == timeout immediately, negative == indefinite. I made sure we only pass None
or >=0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, we don't need to have timeout_s < 0
checking?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know what you mean. self.request_timeout_s
will always be set to None
if it's <0 in the constructor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't curr_timeout_s = timeout_s - (time.time() - start)
make curr_timeout_s
negative?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let me fix and add unit tests
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch. I added this to utils.py::calculate_remaining_timeout
and added a test case for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a small comment on how we set timeout, but otherwise LGTM
else: | ||
curr_timeout_s = timeout_s - (time.time() - start) | ||
|
||
obj_ref = await obj_ref_generator._next_async(timeout_s=curr_timeout_s) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, we don't need to have timeout_s < 0
checking?
@@ -56,6 +58,7 @@ | |||
"RAY_SERVE_HTTP_REQUEST_MAX_RETRIES cannot be negative." | |||
) | |||
|
|||
TIMEOUT_ERROR_CODE = "timeout" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
normally, the error code is a string of number? Is the timeout error code exposing to the users?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's just for metrics. we already have one for disconnects (just below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for addressing my comments!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI to reviewers: the diff grew because I refactored the tests to pull the timeout tests into |
5944681
to
cd6f29a
Compare
cd6f29a
to
e15bc5e
Compare
23d9d50
to
75f6e2f
Compare
Signed-off-by: Edward Oakes <[email protected]>
Signed-off-by: Edward Oakes <[email protected]>
Signed-off-by: Edward Oakes <[email protected]>
Signed-off-by: Edward Oakes <[email protected]>
…aming-on-by-default
Signed-off-by: Edward Oakes <[email protected]>
…rimental streaming flag turned on (ray-project#36261) This is the penultimate PR for turning RAY_SERVE_EXPERIMENTAL_STREAMING on by default. In this change, we are now running all Serve tests under three conditions: - RAY_SERVE_EXPERIMENTAL_STREAMING=0 && RAY_SERVE_ENABLE_NEW_ROUTING=0 - RAY_SERVE_EXPERIMENTAL_STREAMING=0 && RAY_SERVE_ENABLE_NEW_ROUTING=1 - RAY_SERVE_EXPERIMENTAL_STREAMING=1 && RAY_SERVE_ENABLE_NEW_ROUTING=1 (Note that RAY_SERVE_EXPERIMENTAL_STREAMING=1 implies RAY_SERVE_ENABLE_NEW_ROUTING so the latter is not explicitly set). This required making two functionality fixes: - Never using the streaming path for Java even if the flag is on. - Implementing timeouts in the streaming path. I could split these into separate PRs, but they can't really be fully tested independently, so opting to combine them here. Signed-off-by: 久龙 <[email protected]>
…rimental streaming flag turned on (ray-project#36261) This is the penultimate PR for turning RAY_SERVE_EXPERIMENTAL_STREAMING on by default. In this change, we are now running all Serve tests under three conditions: - RAY_SERVE_EXPERIMENTAL_STREAMING=0 && RAY_SERVE_ENABLE_NEW_ROUTING=0 - RAY_SERVE_EXPERIMENTAL_STREAMING=0 && RAY_SERVE_ENABLE_NEW_ROUTING=1 - RAY_SERVE_EXPERIMENTAL_STREAMING=1 && RAY_SERVE_ENABLE_NEW_ROUTING=1 (Note that RAY_SERVE_EXPERIMENTAL_STREAMING=1 implies RAY_SERVE_ENABLE_NEW_ROUTING so the latter is not explicitly set). This required making two functionality fixes: - Never using the streaming path for Java even if the flag is on. - Implementing timeouts in the streaming path. I could split these into separate PRs, but they can't really be fully tested independently, so opting to combine them here. Signed-off-by: harborn <[email protected]>
…rimental streaming flag turned on (ray-project#36261) This is the penultimate PR for turning RAY_SERVE_EXPERIMENTAL_STREAMING on by default. In this change, we are now running all Serve tests under three conditions: - RAY_SERVE_EXPERIMENTAL_STREAMING=0 && RAY_SERVE_ENABLE_NEW_ROUTING=0 - RAY_SERVE_EXPERIMENTAL_STREAMING=0 && RAY_SERVE_ENABLE_NEW_ROUTING=1 - RAY_SERVE_EXPERIMENTAL_STREAMING=1 && RAY_SERVE_ENABLE_NEW_ROUTING=1 (Note that RAY_SERVE_EXPERIMENTAL_STREAMING=1 implies RAY_SERVE_ENABLE_NEW_ROUTING so the latter is not explicitly set). This required making two functionality fixes: - Never using the streaming path for Java even if the flag is on. - Implementing timeouts in the streaming path. I could split these into separate PRs, but they can't really be fully tested independently, so opting to combine them here.
…rimental streaming flag turned on (ray-project#36261) This is the penultimate PR for turning RAY_SERVE_EXPERIMENTAL_STREAMING on by default. In this change, we are now running all Serve tests under three conditions: - RAY_SERVE_EXPERIMENTAL_STREAMING=0 && RAY_SERVE_ENABLE_NEW_ROUTING=0 - RAY_SERVE_EXPERIMENTAL_STREAMING=0 && RAY_SERVE_ENABLE_NEW_ROUTING=1 - RAY_SERVE_EXPERIMENTAL_STREAMING=1 && RAY_SERVE_ENABLE_NEW_ROUTING=1 (Note that RAY_SERVE_EXPERIMENTAL_STREAMING=1 implies RAY_SERVE_ENABLE_NEW_ROUTING so the latter is not explicitly set). This required making two functionality fixes: - Never using the streaming path for Java even if the flag is on. - Implementing timeouts in the streaming path. I could split these into separate PRs, but they can't really be fully tested independently, so opting to combine them here. Signed-off-by: e428265 <[email protected]>
Why are these changes needed?
This is the penultimate PR for turning
RAY_SERVE_EXPERIMENTAL_STREAMING
on by default.In this change, we are now running all Serve tests under three conditions:
RAY_SERVE_EXPERIMENTAL_STREAMING=0 && RAY_SERVE_ENABLE_NEW_ROUTING=0
RAY_SERVE_EXPERIMENTAL_STREAMING=0 && RAY_SERVE_ENABLE_NEW_ROUTING=1
RAY_SERVE_EXPERIMENTAL_STREAMING=1 && RAY_SERVE_ENABLE_NEW_ROUTING=1
(Note that
RAY_SERVE_EXPERIMENTAL_STREAMING=1
impliesRAY_SERVE_ENABLE_NEW_ROUTING
so the latter is not explicitly set).This required making two functionality fixes:
I could split these into separate PRs, but they can't really be fully tested independently, so opting to combine them here.
Related issue number
Closes #35779
Checks
git commit -s
) in this PR.scripts/format.sh
to lint the changes in this PR.method in Tune, I've added it in
doc/source/tune/api/
under thecorresponding
.rst
file.