[
https://issues.apache.org/jira/browse/THRIFT-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17364338#comment-17364338
]
Asaf Mesika edited comment on THRIFT-1948 at 6/16/21, 3:03 PM:
---------------------------------------------------------------
What happened to this feature - did it get in?
was (Author: amesika):
What happened to this features - did it get in?
> Add a stream type
> -----------------
>
> Key: THRIFT-1948
> URL: https://issues.apache.org/jira/browse/THRIFT-1948
> Project: Thrift
> Issue Type: New Feature
> Components: Wish List
> Reporter: Carl Yeksigian
> Assignee: Carl Yeksigian
> Priority: Major
> Labels: push
>
> This is a proposal for an addition to the Thrift IDL, which allows for
> sending chunks of data between the server and the client without having the
> whole message in memory at the start of the communication.
> Here are two use cases where I have been thinking about the possibility of
> using streams.
> LockServer.thrift:
> {code}
> struct Update {
> 1: required string lock_handle,
> 2: required i64 owner
> }
> service LockService {
> stream<Update> updates_for(1: string prefix)
> }
> {code}
> This would allow the LockServer to push out updates that happen based on the
> prefix the client has specified, rather than the constant polling that would
> currently be required to imitate this interface.
> ManyResults.thrift:
> {code}
> service QueryProvider {
> stream<Result> run_query()
> }
> {code}
> This allows the query provider to run the query and send back the results as
> they come in, rather than having to bunch them up, or provide a way to page
> through the results to the client.
> The new keyword, "stream<T>", would indicate that there is a series of values
> typed T which would be communicated between client and server. Stream would
> have three primitives:
> {code}
> next(T)
> error(TException)
> end()
> {code}
> Protocols would be enhanced with the following methods:
> {code}
> writeStreamBegin(etype, streamid)
> writeStreamNext(streamid, streamMessageType)
> writeStreamNextEnd()
> writeStreamErrorEnd()
> etype, streamid = readStreamBegin()
> streamid, streamMessageType = readStreamNext()
> readStreamNextEnd()
> readStreamErrorEnd()
> {code}
> streamMessageType is one of the following:
> # next
> This means that the message will be of the element type.
> # error
> An exception was thrown during materialization of the stream.
> The stream is now closed.
> # end
> This means that the stream is finished.
> The stream is now closed.
> Once all streams are closed, readMessageEnd should be called. Before the
> first writeStreamNext() could be called, the message should otherwise be
> complete. Otherwise, an exception should be raised.
> It is possible that an exception will be thrown while the stream is being
> materialized; however, this can only occur inside of a service. In this case,
> error() will be called; the exception should be one of the exceptions that
> the service call would have thrown. The values that were generated before the
> exception will generally be valid, but may only have meaning if the stream is
> ended. All streams which are currently open may get the same exception.
> If the following service was defined:
> {code}
> stream<i64> random_numbers(stream<i64> max)
> {code}
> A sample session from client to server would be:
> {code}
> writeMessageBegin()
> writeStreamBegin(I64, 0)
> writeStreamNext(0, next)
> writeI64(10)
> writeStreamNextEnd()
> writeStreamNext(0, end)
> writeMessageEnd()
> {code}
> A sample session from server to client would be:
> {code}
> writeMessageBegin()
> writeStreamBegin(i64, 0)
> writeStreamNext(0, next)
> writeI64(3)
> writeStreamNextEnd()
> writeStreamNext(0, end)
> writeMessageEnd()
> {code}
> This change would not be compatible with previous versions of Thrift. Also,
> for languages which do not support this type of streaming, it could be
> translated into a list.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
