Thanks Carl. I'm trying to use async calls without streaming.
On Monday, November 12, 2018 at 5:37:56 PM UTC+5:30, qplc wrote:
>
> Hi,
>
> I've implemented below service definition in my grpc server/client
> application.
>
> service TestService {
> rpc testRPCCall(stream Test) returns (stream
I see. thanks
On Thursday, November 15, 2018 at 2:01:06 PM UTC-5, Carl Mastrangelo wrote:
>
> Future stub is only suitable for Unary RPCs. If you look at how the stub
> library is implemented, BlockingStubs wrap the FutureStubs, which wrap the
> regular Stubs, which themselves wrap ClientCall
Future stub is only suitable for Unary RPCs. If you look at how the stub
library is implemented, BlockingStubs wrap the FutureStubs, which wrap the
regular Stubs, which themselves wrap ClientCall and ServerCall. All are
layers on top of the other, and get more advanced the farther down the
Why not using FutureStub? Seems it returning a ListenableFuture already for
client to use it?
在 2018年11月14日星期三 UTC-5下午2:28:56，Carl Mastrangelo写道：
>
> Yes. It is still async.
>
> Do be aware that flow control works slightly differently for RPCs that
> don't have "stream" on them (we call
Yes. It is still async.
Do be aware that flow control works slightly differently for RPCs that
don't have "stream" on them (we call these "unary" RPCs). This is not
usually an issue unless you are sending very fast or lots of data (like
sustained Gigabits per second).
On Wednesday,
Thank you Carl for your response.
What if I don't use prefix 'stream' in service definition, shall rpc calls
still be executed in asynchronous manner by implementing
TestServiceGrpc.TestServiceStub?
Modified service def:
service TestService {
rpc testRPCCall(Test) returns (Test) {}
}
On
TestServiceStub is the main asynchronous stub, and is built around the idea
of the Observable / Observer pattern. RxJava uses this pattern, for
instance.
One thing to note, if you don't like those stubs, you can call the
ClientCall and ClientCall.Listener directly. You can't use the
