[grpc-io] Re: Problem with the design of the async grpc model

[Weidong Lian]

Hi White,


   1. Is it possible that you abstract and implement your actual calls 
   outside the grpc framework. You can still use protobuf to organize your 
   calls, instead of defining a lot of grpc methods, you define only one 
   async grpc method streaming on both sides. In the streamed message, you can 
   have something similar as below. Then after running the method, you return 
   the uuid with the any method_reply. I just happen to pop up this idea and 
   maybe it is more complicated in your case. Anyway, we can try to use more 
   protobuf but should not heavily tie to async grpc methods. grpc async 
   methods are not so easy to use, especially combined with streaming. I do 
   not see any example or detailed documentation, tricky to handle it 
   correctly. I sometimes questioned that grpc is widely used inside Google. 
   2. You can check this version simplified call data 
   
,
 
   see if helps a bit. I think it is possible that you can wrapper async 
   methods inside your own defined AsyncServiceImpl, but I do not think it 
   will be as elegant as the synced service.  

I am also interested to see how the googlers handle these issues in their 
own products.

Thanks,
Weidong

message Command{
  string uuid;
  EnumService service;
  EnumMethod method;
  any method_request;
}


In the server side, you unpack the message which includes all the 
information to make the actual calling. It adds an extra layer to run the 
actual call outside of the grpc framework. 
Yes, it adds a bit extra complexity, but your implementation is less 
dependent of grpc, you can even switch to socket/websocket easily. 

On Friday, March 16, 2018 at 11:13:02 AM UTC+1, White Sword wrote:
>
> My team is designing a scalable solution with micro-services architecture 
> and planning to use gRPC as the transport communication between layers. And 
> we've decided to use async grpc model. The design that example(
> greeter_async_server.cc 
> )
>  
> provides doesn't seem viable if I scale the number of RPC methods, because 
> then I'll have to create a new class for every RPC method, and create their 
> objects in `HandleRpcs()` like this Pastebin 
>  (complete code).
>
> 
> void HandleRpcs() {
> new CallDataForRPC1(_, cq_.get());
> new CallDataForRPC2(_, cq_.get());
> new CallDataForRPC3(, cq_.get());
> // so on...
> }
>
>
>
> It'll be hard-coded, all the flexibility will be lost.
>
> I've around 300-400RPC methods to implement and having 300-400 classes 
> will be cumbersome and inefficient when I'll have to handle  >100K RPC 
> requests/sec and this solution is a very bad design. I can't bear the 
> overhead of creation of objects this way on every single request. Can 
> somebody kindly provide me a workaround for this. Can async grpc c++ not be 
> simple like its sync companion?
>
> TIA
>

-- 
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/44622fc1-1f29-420a-aed3-b04c33f34145%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Evaluating grpc for cross-platform project

[Nicolas Noble]

There is absolutely no way gRPC can work on Arduino in its current form,
and probably will never be. First, gRPC requires either posix network
sockets, or windows sockets. Arduino - and most other microcontrollers -
only have LWIP, and we don't have a port for this. Second, the core is
written in C++, and is moving more and more towards requiring a full STL to
work. Arduino, as with most other microcontrollers, doesn't have a
libstdc++ that would be acceptable there.

On Thu, Apr 12, 2018 at 11:56 AM, 'Vijay Pai' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Thanks for your questions. I'll let someone else respond to #1.
>
> On Tuesday, February 27, 2018 at 12:50:26 AM UTC-8, Xintong Zhou wrote:
>>
>> 2. grpc on Arduino
>>
>> Have you encountered any issues / performance issues when issuing grpc
>> requests from Arduino with encryption? We are a little concerned over
>> Arduino's processing power and memory.
>>
>
> Interestingly, it looks like no issues about Arduino have been posted to
> the grpc/grpc repository. I have seen other github or other source repos
> that offer Arduino platform services for gRPC using Python or Node, but no
> issues on the grpc/grpc repo.
>
> 3. grpc/http2 max concurrent stream limit
>>
>> We read that grpc server can set max concurrent stream limit. Will client
>> encounter rst_stream if it already has a lot of pending gRPC calls? What is
>> the best practice on setting max concurrent stream limit?
>>
>
> Streams that are above the concurrency limit won't get processed right
> away but may or may not get a RST depending on whether they just get
> stalled (in which case they won't get it) or are actually turned away since
> the system realizes that the stream will never get processed. We haven't
> recommended a best practice on this for now.
>
>
>> 4. grpc for external facing services
>>
>> Is grpc ready for external facing services? We plan to run external
>> facing grpc servers behind server-side L4 loading balancer. Are there any
>> security and/or DoS concerns?
>>
>
> gRPC has been running numerous external facing services for a while now.
> https://grpc.io/docs/guides/auth.html is a guide for authentication, and
> numerous companies have posted their best practices in deployment. A bunch
> of different resources are linked from https://github.com/grpc-
> ecosystem/awesome-grpc . Hope that helps!
>
> - vjpai
>
>
>> We really appreciate your help!
>>
>> Regards,
>> Xintong
>>
> --
> 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/07fc9fd8-4407-46d5-8e9a-2810b1e5d4da%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/CAEvr0PGd%3DnbWbJww2QaDGK2hXsneckw8ourghMG_tL75U0PqMw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: GRPC + Node, what's the destination?

[Nicolas Noble]

Bonjour Arnaud,

  The answer to your question really depends on what you really need and
want. The pure javascript version of grpc isn't released yet, and when it
is, it will be in alpha state. We won't support anything else than basic
grpc client features at first, but we're planning to listen to feedback and
add features to it accordingly. If you are adventurous, you could try
cloning the repository and trying the code directly. But I wouldn't expect
this code to be production-ready. Also, contrary to what you are saying,
it's not protobufjs-centric. You can use both protobuf and protobufjs with
this code.

  The native version of gRPC is today the fully featured version of
grpc-node, with high performance client and server code, compression
support, retries, etc. If you need all of these features, in a
production-ready package, that's where you should look at. Note that any
code that works with the pure javascript version of grpc will also work
with the native version too.

  Finally, as dynamic vs static codegen (or protobufjs vs protobuf) are
concerned, we're not opinionated about it. Both have pros and cons, and you
should just use whichever fits your usage case better. We're supporting
both for the foreseeable future.

  Don't hesitate to let us know if you have further questions. Bon courage!

  -- Nicolas


On Fri, Apr 13, 2018 at 8:07 AM, Michael Lumish 
wrote:

> +grpc-io@googlegroups.com 
>
> On Fri, Apr 13, 2018 at 7:01 AM Arnaud Dematte <
> arnaud.dema...@fr.clara.net> wrote:
>
>> Hi Michael,
>>
>>
>> first, thanks for all the good work you've been doing on grpc/node !
>>
>>
>> I've been working with GRPC for more than a year and I am a bit puzzled
>> about where NodeJs support is heading.
>>
>>
>> Currently there are 3 ways to handle GRPC client/server from NodeJS:
>>
>> - grpc-native-core with dynamic codegen (seems to be using protobufjs
>> under the hood)
>>
>> - grpc-native-core with static codegen (using protoc which unfortunately
>> requires grpc object to be created using getter/setter which is quite
>> ill-suited for the ecmascript community)
>>
>> - grpc-js-core which is still in alpha and seems to be wrapping
>> protobufjs to implement the grpc service part which the lib does not handle.
>>
>>
>> We are using Node (typescript) in our node projects and are looking for
>> the best approach possible. I would personally bet on the native
>> grpc-js-core because it seems to better fit the javascript ecosystem but what
>> do you personally feel is the future for grpc in Node ?
>>
>>
>> cheers,
>>
>>
>> --
>> Arnaud DEMATTE
>>
>> *Chief Innovation Officer *
>>
>> *Claranet France – Runiso Critical Data *arnaud.dema...@fr.clara.net
>> Office +33 (0) 3 62 13 83 76 <+33%203%2062%2013%2083%2076>
>> 167 avenue de Bretagne, 59000 Lille
>> 
>> www.runiso.com - www.claranet.fr
>>
>> --
> 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/CAO8e_2LsJB8kN1e6BCiTd8DuN%2Bkr-QRwQQsAkMZ%2BmKvUKQPfSw%
> 40mail.gmail.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/CAEvr0PHyhimKenRafr3Laqh5DOA68Xdmhu70urTJoCeDMadtng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [Java] Server-side streaming - server doesn't detect when client disappears

[Christopher Schechter]

Hm, I would have thought that seeing the TCP connection broken would at 
some point cause StreamObserver.onNext() (on the server side) to complain.

I've set all four options you mentioned on my Netty server. When the gRPC 
starts, the server enters a loop where it calls StreamObserver.onNext() 
basically forever until the server shuts down, at which point it calls 
onCompleted().

When the connection from client to server is made, I can see keepalive 
pings via the grpc debug logs. Once the time surpasses the maxConnectionAge 
+ grace period, the client disconnects. I'm assuming this is an 
"ungraceful" disconnect, since it only disconnects once the grace period is 
over (as the stream is still producing more messages).

However, the server continues to execute its loop calling onNext() ad 
infinitum. It seems to completely ignore that the client no longer accepts 
messages, nor does it respond to the keepalive pings. So now it looks like 
my problem is that the server *never* recognizes that the client has 
disappeared.

Here's my server configuration. The time values aren't meant to be 
realistic, I just wanted to see the behavior in a manual test:

Server server = NettyServerBuilder.forPort(port)
.addService(testService)
.executor(Executors.newFixedThreadPool(5))
.keepAliveTime(10, TimeUnit.SECONDS)
.keepAliveTimeout(10, TimeUnit.SECONDS)
.maxConnectionAge(30, TimeUnit.SECONDS)
.maxConnectionAgeGrace(5, TimeUnit.SECONDS)
.maxConnectionIdle(5, TimeUnit.SECONDS)
.build();

Inside testService, it has this server-side streaming method:

// for the purpose of this test, this queue is pre-filled with a handful of 
StreamItems, and never has any other objects added to it   
BlockingQueue queue = new LinkedBlockingQueue<>();

@Override
public void testStream(StreamRequest request, 
StreamObserver responseObserver) {
try {
while (!Thread.interrupted()) {
StreamItem next = queue.poll();
if (next == null) {
LOGGER.debug("Queue is empty, waiting before next 
poll()");
Thread.sleep(1000);
// send default instance which is empty, to signal that 
the queue is empty right now

responseObserver.onNext(StreamItem.getDefaultInstance());
} else {
responseObserver.onNext(next);
}
}
} catch (InterruptedException e) {
LOGGER.info("Interrupted. Exiting loop.");
} catch (Exception e) {
LOGGER.error("Unexpected error", e);
responseObserver.onError(e);
return;
}
responseObserver.onCompleted();
}

And here's my test client code:

ManagedChannel channel = ManagedChannelBuilder.forTarget(target)
.usePlaintext(true)
.build();

TestServiceGrpc.TestServiceBlockingStub blockingStub = 
TestServiceGrpc.newBlockingStub(channel);

try {
Iterator stream = 
blockingStub.testStream(subscriptionRequest);
while (stream.hasNext()) {
LOGGER.debug("Received an item:\n{}", stream.next());
}
} catch (StatusRuntimeException e) {
LOGGER.error("GRPC Exception: {}", e.getStatus());
}

Is there something wrong here? I feel like I'm missing something.


On Thursday, April 12, 2018 at 2:35:19 PM UTC-7, Carl Mastrangelo wrote:
>
> This can be eventually detected by 
> setting keepAliveTime(), keepAliveTimeout(), maxConnectionIdle(), 
> maxConnectionAge(), and so forth on your ServerBuilder.
>
> In general, it's not possible to quickly detect if the remote side has 
> silently stopped, so the best we can do is actively check, and set 
> timeouts. 
>
> On Thursday, April 12, 2018 at 2:07:54 PM UTC-7, Christopher Schechter 
> wrote:
>>
>> Hi all,
>>
>> I'm working on setting up a server-side stream GRPC. When the stream is 
>> started, the server should stream messages to the client until either the 
>> server or the client shuts down.
>>
>> When the server shuts down, this is easy - it calls 
>> StreamObserver.onCompleted() and the client is then notified that the 
>> stream is ending.
>>
>> When clients shut down, they can do a graceful shutdown with 
>> ManagedChannel.shutdownNow() to stop the stream from their end. However, 
>> when the client shuts down ungracefully, the server never notices, and can 
>> continue to call StreamObserver.onNext() basically forever.
>>
>> My question is, is there a way to detect this situation from the server 
>> side when the client shuts down ungracefully? I would expect an exception 
>> to be thrown at some point, but that never happens. Can I manually check 
>> something to see whether the connection is broken?
>>
>> I've seen one other mention of a similar/same issue in this topic 
>> , 
>> which is from a long time ago but I 

[grpc-io] Re: GRPC + Node, what's the destination?

[Michael Lumish]

+grpc-io@googlegroups.com 

On Fri, Apr 13, 2018 at 7:01 AM Arnaud Dematte 
wrote:

> Hi Michael,
>
>
> first, thanks for all the good work you've been doing on grpc/node !
>
>
> I've been working with GRPC for more than a year and I am a bit puzzled
> about where NodeJs support is heading.
>
>
> Currently there are 3 ways to handle GRPC client/server from NodeJS:
>
> - grpc-native-core with dynamic codegen (seems to be using protobufjs
> under the hood)
>
> - grpc-native-core with static codegen (using protoc which unfortunately
> requires grpc object to be created using getter/setter which is quite
> ill-suited for the ecmascript community)
>
> - grpc-js-core which is still in alpha and seems to be wrapping protobufjs
> to implement the grpc service part which the lib does not handle.
>
>
> We are using Node (typescript) in our node projects and are looking for
> the best approach possible. I would personally bet on the native
> grpc-js-core because it seems to better fit the javascript ecosystem but what
> do you personally feel is the future for grpc in Node ?
>
>
> cheers,
>
>
> --
> Arnaud DEMATTE
>
> *Chief Innovation Officer *
>
> *Claranet France – Runiso Critical Data *arnaud.dema...@fr.clara.net
> Office +33 (0) 3 62 13 83 76 <+33%203%2062%2013%2083%2076>
> 167 avenue de Bretagne, 59000 Lille
> 
> www.runiso.com - www.claranet.fr
>
>

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