-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Allow configuration of the queued byte threshold at which a Stream is considered not ready #10977
Allow configuration of the queued byte threshold at which a Stream is considered not ready #10977
Conversation
jduo
commented
Mar 2, 2024
- on clients this is exposed by setting a CallOption
- on servers this is configured by calling a method on ServerCall or ServerStreamListener
This is a draft to demonstrate the idea discussed in #5433 @ejona86:
|
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.
Quick drive-by review. I think client-side will clean up nicely by my comment. Still need to look at server-side more.
34b0da1
to
959473b
Compare
Hey @ejona86 , any more feedback? Particularly about the server side. |
Hi @ejona86 , checking in on if there's an update. I'm hoping to get this in March, the earlier the better. The Arrow project has a 3-month release cycle and there's a code freeze coming up at the end of March, and I'll be away for a from March 23rd until April. Thanks! |
gRPC's next release is April 2nd, so the release cycles may not align for you |
Thanks for the update. Yeah more realistically this will get into Arrow 17. We can still have Arrow Flight server developers use this before it officially makes it into Arrow though. Server developers can create the gRPC server themselves, configure this option, then apply the Arrow Flight stub. |
253fae4
to
75816e0
Compare
I've added server tests now. I don't have tests for the TransmitStatusRuntimeExceptionInterceptor since I wasn't really sure how to use it. Hopefully this covers everything @ejona86 |
eb95ab5
to
98e228a
Compare
…urable - on clients this is exposed by setting a CallOption - on servers this is configured by calling a method on ServerCall or ServerStreamListener
98e228a
to
9024da0
Compare
Hi @ejona86 , just wondering if you had a chance to look. I'll be away at the end of the week until the 3rd so it'd be great if we could get this wrapped up. Maybe this could get into 1.63 if it all looks OK. |
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.
Please make your review changes as additional commits. When you squash the commits together during review it means I have to re-review the entire thing instead of only looking at your changes, which delays the review. We will squash the commits before merging to master.
util/src/main/java/io/grpc/util/TransmitStatusRuntimeExceptionInterceptor.java
Outdated
Show resolved
Hide resolved
inprocess/src/main/java/io/grpc/inprocess/InProcessTransport.java
Outdated
Show resolved
Hide resolved
At this point is this "I'll be gone tomorrow"? If so (if you have no time), I'd accept this with the threshold checks in OkHttpClientStream and the like. But we do need to get some of the other easier things resolved. |
I've covered the javadoc-related ones mostly now. If you can give some more guidance around the AbstractClientStream constructor I can pick that up too. Thanks! |
* Change setting on client to happen during TransportState constructor * Fix checkstyle issues
The failure in JDK 8 testing looks unrelated. Is it flakey? |
Yeah, |
Looks like there are some Android classes that need to be updated (SingleMessageServerStream and MultiMessageServerStream). These seem to use a different class hierarchy than using a Transport so I'm not sure what the implementation entails. For now I'm just going to make setOnReadyThreshold() a no-op. Unfortunately my Android Studio installation isn't working right so I'm having difficulty seeing Android build issues locally and am only spotting them through Kokoro. |
No-op is fine. Since the Android build requires us to add the "kokoro:run" label for each change, it might make sense for us to fix it up instead of you. Do you have a change there in-flight, or is it safe to push to your branch? |
Implementations of ServerStream
I added no-ops for the two ServerStream implementations in binder. No other changes in-flight. |
I just built your "Fix Android build" commit locally and it worked fine. So the Android CI should turn green this time. |
@jduo, thank you! This made it in before the 1.63 branch cut, so it will be in the next release. (The branch cut was scheduled for Tuesday, but it had been forgotten about a bit so hasn't been done yet.) |
Thanks for your help getting this in for our timeline @ejona86 @larry-safran ! |