Re: [grpc-io] Re: Java -server -> client blocking queue?

['Eric Anderson' via grpc.io]

You can check out my "example" in issue 2247
.

On Fri, Oct 28, 2016 at 8:32 AM, Matt Mitchell  wrote:

> So if I'm emitting a stream from my server, should I be checking isReady()
> before each onNext() call?
>

You should check it occasionally; it doesn't have to be done for every
message. I'd suggest checking it _after_ onNext(); if you already have a
message, go ahead and send it; just delay creating more messages.

Java's flow control is advisory: gRPC tells you when it is no longer
productive to queue more messages and you stop when convenient. But
anything you queue will be queued, so you have to be aware of how much
memory you may be wasting.

I'm currently reading an InputStream and chunking out to the response, so
> really what I'm doing is "waiting" (while/sleep) for isReady to be true on
> each read from the InputStream.
>

That's fair, although we provide a callback like I showed in the link
above. Again, I'd suggest calling onNext() first and then if isReady() is
false, just delay calling read().

I really wish there were a way to do a blocking stream write/read so the
> backpressure handling was driven by the client reads.
>

Which would be a blocking API, which Stream Observer is not. We would like
to have blocking APIs server-side, but it wasn't clear what the "idiomatic"
Java API would be. Streaming can also be hard (especially bi-di) because it
is easy for you to deadlock if you aren't careful.

Having to wait/sleep or react to asynchronous messages in the server (for
> example, client could send a "pause" message, server could "sleep") feels
> complicated and brittle.
>

The setOnReadyHandler makes it reasonable. It is still an async API, which
has its advantages and downfalls.

-- 
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/CA%2B4M1oO5qDMKgPUQeQF56SoqzmTuoQ2wmdP06kC076Jca7JZsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Java -server -> client blocking queue?

[Matt Mitchell]

Thanks Avinash. I tried your example and it does seem to help. So if I'm 
emitting a stream from my server, should I be checking isReady() before 
each onNext() call? I'm currently reading an InputStream and chunking out 
to the response, so really what I'm doing is "waiting" (while/sleep) for 
isReady to be true on each read from the InputStream. This does seem to 
prevent the server throwing an OOM but not sure if this is the best way?

I really wish there were a way to do a blocking stream write/read so the 
backpressure handling was driven by the client reads. Having to wait/sleep 
or react to asynchronous messages in the server (for example, client could 
send a "pause" message, server could "sleep") feels complicated and 
brittle. Am I missing something with how I'm approaching this?

On Tuesday, October 25, 2016 at 1:55:29 AM UTC-4, Avinash Dongre wrote:
>
> I was trying out "flow control" see the example here
>
>
> https://github.com/davinash/grpc-bench/blob/master/bench/src/main/java/io/adongre/grpc/formatted/ScanFormattedServiceImpl.java
>
> Thanks
> Avinash
>
>
> On Sunday, October 23, 2016 at 8:51:35 PM UTC+5:30, Matt Mitchell wrote:
>>
>> After digging a little, it seems there is support for "flow control", 
>> although I can't seem to find any examples of how to do this. I've seen 
>> references to ClientResponseObserver, but not finding any way to integrate 
>> this either. Any pointers on how to work with gRPC's flow control - more 
>> importantly, am I on the right track here?
>>
>> - Matt
>>
>>  I just need to make sure that if the client isn't consuming quickly 
>> enough, that the server doesn't continue to push data into its buffer and 
>> then run out of memory.
>>
>> On Saturday, October 22, 2016 at 5:41:04 PM UTC-4, good...@gmail.com 
>> wrote:
>>>
>>> Hi,
>>>
>>> I'm messing around with a Java server/client impl with grpc and would 
>>> like to have the Server stream back chunks from an InputStream. The 
>>> chunking using a bytes type seems fine, but now I'm wondering if there's a 
>>> way to do some sort of blocking-queue, so that if the client slows down 
>>> reading, the server will slow down too (I'm getting 
>>> "java.lang.OutOfMemoryError: Direct buffer memory" in the server) -- Is 
>>> this possible?
>>>
>>> Thanks!
>>>
>>

-- 
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/a23c2422-a02b-40fd-ba23-3144519a8f34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Concurrency in synchronous c++ service

[Jan Willem]

Cool, thanks for the confirmation!

2016-10-27 17:01 GMT+02:00 Craig Tiller :

> Server methods can absolutely be called from many threads.
>
> On Thu, Oct 27, 2016 at 7:28 AM  wrote:
>
>> Hi,
>>
>> In the synchronous case (example: http://www.grpc.io/docs/
>> tutorials/basic/c.html), are the functions executed concurrently, or
>> sequentially?
>> For instance in the example, is RouteGuideImpl::GetFeature called
>> concurrently (from multiple threads from the same time).
>>
>> I've implemented such a service, but there is shared state. From my
>> experiments it is quite clear that these functions can be called
>> concurrently, but there is no reference to that in the documentation. I
>> have tried to find this out before writing the code, but (to me) it is not
>> clear from the documentation what to expect.
>>
>> Some messages on this mailing list also ask questions about the threading
>> model, but there is no clear answer to my question.
>>
>> I'd be happy to do a pull request on the documentation repository, but I
>> first wanted to have some confirmation.
>>
>> Thanks!
>> Kind regards,
>> Jan.
>>
>> --
>> 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/5ae50e4d-7a88-4a9b-b897-447cf3331dfd%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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/CACEbKM3nx9COS2w9h-9a0W%2BQfqKZ8p5zdNZGBNMsvpoPyxczSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.