#grpc

hi

Woo! Trailers in browsers! https://github.com/whatwg/fetch/issues/34#issue...

That's just for the spec. We'll still get to see how many browsers implement it (and when)

yes, I saw that as well :)

Hi all, anyone have some bandwidth to go over some Python gRPC issues? Trying to fix them on my end, but could use some more experienced input to point my efforts in the right direction.

Issues with gRPC itself, not code using it.

we can try to answer a few questions :)

if the questions are grpc specific, maybe anyone can answer

if it's python-specific, we'll have to drag pythong people in the channel

-g

Ah wonderful. It is Python specific and gRPC specific. Having some issues with server-side streams, trying to debug where things are going wrong either in the python wrapper or core, uncertain. Believe it's just the python wrapper.

let me try to get one of the python devs here :)

Thanks, let me gather everything I think I've found so far...

Ken who just joined is one of our Python devs

Hey Ken, thanks for coming. So my issue relates back to https://github.com/grpc/grpc/issues/7192

The whole idea of a subscription is pretty useful here, but mainly I am trying to get back a continuous server-side stream of contents. That doesn't seem to be fully implemented yet.

It appears that there is some problem where the socket or something isn't kept alive. I'm not incredibly familiar with how grpc works overall - but I know this works in Go.

the issue you've linked is somewhat confusing

are you the original author of it ?

that aside, what you're talking about really is the streaming feature of gRPC, and it's supposed to work

No I'm not, but it is related. Some more details on what's happening in my case...the call I am making is returning a _Rendezvous object from the beta API.

Is that expected?

For a server side stream.

kpayson64 ?

No I wouldn't expect that, I need to take a look at your example to get better context though

Alright let me try and get you some good snippets that give you a better picture. Is this the right place to do this? This and the mailer were the two resources I could find.

I'm looking at the github linked in the original issue, is that still correct?

A good amount of it is something I believe is related. A subscription is ultimately what I want here. Data will be sent at intervals over the channel (or stream, semantics...) so I need it to stay alive and have callbacks to handle the data. At this point I'm just trying to determine how to best go about this. I tried to add callbacks to the rendezvous object, and call next() hoping it might be equivalent to the Golang Recv() and b

be the case

I tried stepping through the debugger but became a little lost in the chain of command. The proto statement here is rpc CreateSubscription(CreateSubArgs) returns(stream CreateSubReply) {};

What you are trying to do should work in principal.

The OUT_OF_RANGE error should never be generated by the grpc library itself, and is likely generated by the server

Okay, trying something. Thanks for the pointer.

The "Subscription mode not implemented yet" error you are seeing also seems like something the server is returning

any considerations around having a ValidationInterceptor on the server-side which validates inbound request messages vs using method interceptors?

Also, the TIMEOUT parameter specifies the timeout for the entire duration of the stream, so if you want a long-lived stream, you should pass float("+inf")

Okay, really useful tips. Maybe I'm not going about this correctly then. So the rpc I stated, when I call it...

stream = self._stub.CreateSubscription(sub_args, self._timeout, metadata=self._metadata)

That returns (when printed) <grpc.beta._client_adaptations._Rendezvous object at 0x7f724b138d10>

So a rendezvous object is returned... If I subscribe to the channel, in principal I should receive data when it is sent after requesting the stream?

Continuously until a timeout is reached? Does it block, or do I need to do the blocking?

Sorry for all the questions, just haven't found any examples that handle this.

The python gRPC channel subscription API monitors connectivity rather than requests, and it sounds like that is not what you are looking for in this case

Just tested and discovered that.

Is there anything that provides the affordance for monitoring/blocking and awaiting data for requests?

The <grpc.beta._client_adaptations._Rendezvous object at 0x7f724b138d10> is an iterable that will block until the next response is available

So performing some statement like: for segment in stream: ... should do it? Explicitly calling .next() raises StopIteration(). The for statement immediately returns.

ChannelConnectivity based on the subscription reads as READY state.

Yes, that should accomplish what you are trying to do. It sounds like the server side is not returning any responses if the for statement exits immediately.

What language is your server in?

Thank you for all the clarifications. Turns out this is an issue with my server right now. Server is in Go. You have definitely answered my original question, thank you!

No problem! Glad I could help.

how would i define a list/array in .proto file? using proto3. looking here- https://developers.google.com/protocol-buffers/..., i see maps but not plain typed lists.