On Tue, Apr 10, 2018 at 2:57 PM, David Matson <dmat...@gmail.com> wrote:
> I have a bi-directional gRPC that writes to a file and returns responses.
> Protobuf is defined roughly like this:
>
> *file.proto*
>
> rpc Write(stream WriteRequest) returns (stream WriteResponse);
>
>
> message FileData {
> int64 offset = 1;
> bytes data = 2;
> }
>
>
> message WriteRequest {
> repeated FileData extents = 1;
> }
>
>
> message WriteResponse {
> int64 throttle = 1;
> }
>
> The issue I'm running into is that I need to run special logic on the last
> request in the iterator before returning a response (e.g. flush buffers).
> The only way I can think to do that is to peek ahead in the iterator
>
Is adding a boolean "is_last_request_in_stream" field to your WriteRequest
message possible? If so, would it afford the information that you need at
the time that you need it?
, but iterator.next() blocks forever if I haven't returned a response since
> the last time I called it.
>
> *file.py*
>
> def Write(self, request_iterator, context):
> request = request_iterator.next()
>
Why request_iterator.next() rather than next(request_iterator)?
> next_request = request
>
>
> while True:
> request = next_request
> for extent in request.extents:
> # Write data
>
>
> # This call blocks forever
>
Forever? It should only block until the remote party on the other side of
the RPC either sends another request or indicates the end of the request
stream.
> next_request = request_iterator.next()
>
(Same question here about .next() rather than next(<...>).)
> if not next_request:
>
What value assigned to next_request satisfies the condition "not
next_request"?
> # Do important stuff before client unblocks
> yield WriteResponse(throttle=0)
> break
>
How certain are you that this break statement is ever executed?
> else:
> yield WriteResponse(throttle=0)
>
> All I'm really trying to accomplish is running some logic at the very end
> of the RPC before the client unblocks. If I was using the Java
> implementation I would have access to ResponseObserver.onCompleted() but it
> seems like with Python, RPC completion is just implied through yield-ing
> the response that corresponds with the last request in the request iterator.
>
> Is there some way to do this?
>
This sounds like a use case that we definitely didn't anticipate, but...
it's still rather surprising that it could matter somehow whether or not
something was done before the end of the stream became known versus after
the end of the stream became known.
I suspect that there's something else going on.
-N
--
You received this message because you are subscribed to the Google Groups
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to grpc-io+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit
https://groups.google.com/d/msgid/grpc-io/CAEOYnATgDgshbPfjvO_OuU4ZfSO5-Q0nB%3DigkYL7XL8CYR6RSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
