You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Love the project! Just one request on response streaming.
Most (because I haven't used all of them) gRPC implementation passes a sink/writer handle into the handler stub. In the stub implementation, users may call sink.send(response) or write.write(response) to stream data to the client. However, tonic makes the handler return a Resonse<RPCStream> type.
This has two issues
This usually leaks tokio::spawn handles; or that user needs to build special apparatus to keep track of these handles.
We exit Layers before stream is completed
Crates
I think just tonic?
Motivation
stream back from inside the handler, instead of a stray tokio task
able to have more control over streaming response in Layers. -- concurrent stream limits, response coalescing, etc.
Proposal
TBD
Alternatives
maybe tonic runtime can take a join handle in the handler return value and wait for the task to finish before exiting the layers? Less powerful then Sink interface but solves the control issue in Layer
The text was updated successfully, but these errors were encountered:
chebbyChefNEQ
changed the title
Use a Sinkargument instead of returning a Stream
Use a Sink argument instead of returning a Stream for response streaming
Mar 13, 2024
The returned stream type is generic, that means that it can be whatever you want. One thing that you can do is move the join handles into the returned stream and make sure cancellation occurs on drop. The other note is that you do not need to ever be doing the spawn directly, but rather can move the logic to a returned stream type -- i.e. you don't need to use something like ReceiverStream.
I think the stream limiting point is the most legit here.
Feature Request
Love the project! Just one request on response streaming.
Most (because I haven't used all of them) gRPC implementation passes a
sink/writer
handle into the handler stub. In the stub implementation, users may callsink.send(response)
orwrite.write(response)
to stream data to the client. However,tonic
makes the handler return aResonse<RPCStream>
type.This has two issues
tokio::spawn
handles; or that user needs to build special apparatus to keep track of these handles.Layer
s before stream is completedCrates
I think just
tonic
?Motivation
Layer
s. -- concurrent stream limits, response coalescing, etc.Proposal
TBD
Alternatives
tonic
runtime can take a join handle in the handler return value and wait for the task to finish before exiting the layers? Less powerful thenSink
interface but solves the control issue inLayer
The text was updated successfully, but these errors were encountered: