Re: [grpc-io] Re: gRPC Performance

['Sree Kuchibhotla' via grpc.io]

Thanks for bringing this to our attention. The numbers look very low for
C++ (especially for unary, its way too low). We are investigating..

thanks,
Sree


On Wed, Mar 7, 2018 at 4:38 PM 'Matt Kwong' via grpc.io <
grpc-io@googlegroups.com> wrote:

> +grpc-io
>
> Unfortunately, I'm not the best person to answer this question. Adding
> grpc-io, so that someone working on C++ or Java performance can answer
> this.
>
> On Wed, Mar 7, 2018 at 4:10 PM, Nan Dun  wrote:
>
>> Hi Matt,
>>
>>
>>
>> This is Nan from Quantcast. Our team at Quantcast is looking for gPRC
>> performance numbers and we are glad to find this very insightful chart:
>> https://performance-dot-grpc-testing.appspot.com/explore?dashboard=5636470266134528
>>
>>
>>
>> However, we are a bit confused, in throughput QPS charts (both unary and
>> streaming), why Java has much better performance (almost 2x) than C++? We
>> do appreciate if you can give us some hints about this. Thank you!
>>
>>
>>
>> Sincerely,
>>
>> Nan
>>
>
> --
> 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/CALc3v%2BOoOwcvFdLuPG7%3DAvaO%2BmKQhT29Kxvb4WthQHLi5Dv9eg%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/CALRi9QdnRfsTkLNj0vhR%2BJei0XWpnA1fVSiwwYZ7ga%2BtAGGpPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Using gRPC on AWS

['yz' via grpc.io]

How to use ALB at Layer 3? it only supports HTTP/HTTPS?


On Saturday, January 21, 2017 at 2:19:46 AM UTC+8, Louis Ryan wrote:
>
> Alternatively use ELB/ALB at Layer-3 but put your own HTTP2 compliant 
> proxy behind it (Envoy, nghttpx, Linkerd, Traefik, ...)
>
> I know Lyft does this in production with Envoy.
>
> On Fri, Jan 20, 2017 at 8:04 AM,  wrote:
>
>> Oh Ok. Good to know. Thanks for the info.
>>
>> On Friday, 20 January 2017 11:45:47 UTC-4, William Thurston wrote:
>>>
>>> I use gRPC on AWS  and it works great. However, I don't believe ALBs 
>>> support trailers in the HTTP/2 spec, so that won't work. Something may have 
>>> changed since the last time I looked, but don't count on an HTTP/2 ALB 
>>> working.  I believe it's HTTP/2 to clients of the ELB but HTTP/1.1 to your 
>>> backend servers. 
>>>
>>> William Thurston
>>>
>>> On Jan 20, 2017, at 7:17 AM, "dbo...@gmail.com"  
>>> wrote:
>>>
>>> I haven't tried using gRPC on AWS but it is on my TODO list in near 
>>> future. 
>>>
>>> Just to add Application Load Balancer does seem to support HTTP/2:
>>> https://aws.amazon.com/blogs/aws/new-aws-application-load-balancer/
>>> https://aws.amazon.com/elasticloadbalancing/classicloadbalancer/faqs/
>>>
>>> So theoretically some kind of ALB + EC2 (and ECS) setup should work.
>>> AFAIK API Gateway and Elastic Beanstalk are not possibilities currently.
>>>
>>> Hope this helps.
>>>
>>> On Thursday, 19 January 2017 10:18:18 UTC-4, al...@ly.st wrote:

 gRPC "works" in AWS. That is, you can run gRPC services on EC2 nodes 
 and have them connect to other nodes, and everything is fine. If you are 
 using AWS for easy access to hardware then all is fine.

 What doesn't work is ELB (aka CLB), and ALBs. Neither of these support 
 HTTP/2 (h2c) in a way that gRPC needs.

 ELBs work in TCP mode, but you give up useful health checking and the 
 join-shortest-queue behaviour that makes normal HTTP mode ELBs good. It 
 also means you may experience problems with how well balanced your cluster 
 is since only individual client connections are balanced rather than 
 individual requests to the backend. If a single client is generating a lot 
 of requests, they will all go to the same backend rather than being 
 balanced across your available instances.

 This also means that ECS doesn't really work properly since it only 
 supports the use of ELB and ALB load balancers.

 If your requirements are not too demanding TCP mode ELBs do work, and 
 you can definitely ship stuff that way. It's just not ideal and has some 
 fairly major problems as your request rates and general system complexity 
 increase.

 On Wednesday, January 18, 2017 at 12:59:40 PM UTC, Daniel Rios wrote:
>
> Hey all, 
>
> I'm interested on trying out gRPC on AWS, but I am new to this and 
> couldn't find examples or documentation related. Is it possible, due the 
> HTTP/2 features?, I also wonder how doable this is. 
>
> 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+u...@googlegroups.com.
>>> To post to this group, send email to grp...@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/d2327ec2-9aa6-47b2-b4bf-a210cb165fb8%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+u...@googlegroups.com .
>> To post to this group, send email to grp...@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/a6a084bb-e264-4a3d-b3a7-3ab56e347781%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
-- 
*Grab is hiring. Learn more at **https://grab.careers 
*

By communicating with Grab Inc and/or its subsidiaries, associate companies 
and jointly controlled entities (“Grab Group”), you are deemed to have 
consented to processing of your personal data as set out in the Privacy 
Notice which can be viewed at https://grab.com/privacy/

This email contains confidential information and is only for the intended 

Re: [grpc-io] Re: [C++] SSL certificate reload api

['Justin Burke' via grpc.io]

Hi Arpit,

Thanks for bringing this to our attention. A C++ API update wasn't in scope
for the initial set of work. I'm working on finding developer time to work
on this, but currently do not have an ETA to provide to you.

Justin


On Thu, Mar 8, 2018 at 10:43 AM, Arpit Baldeva  wrote:

> Any information on this?
>
> Thanks.
>
> On Thursday, March 1, 2018 at 3:41:58 PM UTC-8, Arpit Baldeva wrote:
>>
>> Hi,
>>
>> Looks like C core added cert reload support (
>> https://github.com/grpc/grpc/pull/12644)  but C++ api does not expose
>> the functionality? Am I missing something here or this is in the works?
>>
>> Thanks.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "grpc.io" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/grpc-io/TUsC_MTIv2U/unsubscribe.
> To unsubscribe from this group and all its topics, 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/44324693-39eb-41bd-a028-131aacf6337a%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/CAD5Ob6c-67qNXz5K9z5SUD%3DcQ1z64GNo1k3o6krNnk48EzgF%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [C++] SSL certificate reload api

[Arpit Baldeva]

Any information on this?

Thanks.

On Thursday, March 1, 2018 at 3:41:58 PM UTC-8, Arpit Baldeva wrote:
>
> Hi,
>
> Looks like C core added cert reload support (
> https://github.com/grpc/grpc/pull/12644)  but C++ api does not expose the 
> functionality? Am I missing something here or this is in the works?
>
> 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/44324693-39eb-41bd-a028-131aacf6337a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Need help with grpc c++ client and java server

[mukul singh]

Hi All,

I am trying to develop a cpp client for a grpc server implemented using 
Java.
With this change, I am trying to develop a cpp client for Apache Ratis 
project.

The client is trying to implement read/write functions for a bi-directional 
append api, as in the Proto file below.

Following are the series of events and results

1)  std::unique_ptr>

cli_stream(stub->Asyncappend(, , (void*)1));


client created a new ClientAsyncReaderWriter and this invokes the stream 
observer constructor on java.


  AppendRequestStreamObserver(StreamObserver ro) {
LOG.info("new AppendRequestStreamObserver {}", name);
this.responseObserver = ro;



2) the next call is for write, to write a RaftClientRequestProto to the stream.

-- this call has no effect on the server. However the 'ok' flag from the 
completion queue return true.


3) the subsequent WritesDone done succeeds as well, and the log entries on 
server also confirm that the stream observer is closed.


org.apache.ratis.grpc.client.RaftClientProtocolService: completed request 



Questions:

1) I would like to invoke the onNext() api on the Java Server.

How can this be achieved from a cpp client.


 Code Below 

Proto:

syntax = "proto3";
option java_package = "org.apache.ratis.shaded.proto.grpc";
option java_outer_classname = "GRpcProtos";
option java_generate_equals_and_hash = true;
package ratis.grpc;

import "Raft.proto";

service RaftClientProtocolService {
  // A client-to-server RPC to set new raft configuration
  rpc setConfiguration(ratis.common.SetConfigurationRequestProto)
  returns(ratis.common.RaftClientReplyProto) {}

  // A client-to-server stream RPC to append data
  rpc append(stream ratis.common.RaftClientRequestProto)
  returns (stream ratis.common.RaftClientReplyProto) {}
}


*Server code:*

private class AppendRequestStreamObserver implements
StreamObserver {
  private final String name = getId() + "-" +  streamCount.getAndIncrement();
  private final StreamObserver responseObserver;
  private final SlidingWindow.Server 
slidingWindow
  = new SlidingWindow.Server<>(name, COMPLETED);
  private final AtomicBoolean isClosed;

  AppendRequestStreamObserver(StreamObserver ro) {
LOG.info("new AppendRequestStreamObserver {}", name);
this.responseObserver = ro;
this.isClosed = new AtomicBoolean(false);
  }

  void processClientRequestAsync(PendingAppend pending) {
try {
  protocol.submitClientRequestAsync(pending.getRequest()
  ).thenAcceptAsync(reply -> slidingWindow.receiveReply(
  pending.getSeqNum(), reply, this::sendReply, 
this::processClientRequestAsync)
  ).exceptionally(exception -> {
// TODO: the exception may be from either raft or state machine.
// Currently we skip all the following responses when getting an
// exception from the state machine.
responseError(exception, () -> "processClientRequestAsync for " + 
pending.getRequest());
return null;
  });
} catch (IOException e) {
  throw new CompletionException("Failed processClientRequestAsync for " + 
pending.getRequest(), e);
}
  }

  @Override
  public void onNext(RaftClientRequestProto request) {
try {
  final RaftClientRequest r = ClientProtoUtils.toRaftClientRequest(request);
  LOG.info("recieved request " + r.getCallId());
  final PendingAppend p = new PendingAppend(r);
  slidingWindow.receivedRequest(p, this::processClientRequestAsync);
} catch (Throwable e) {
  responseError(e, () -> "onNext for " + 
ClientProtoUtils.toString(request));
}
  }

  private void sendReply(PendingAppend ready) {
  Preconditions.assertTrue(ready.hasReply());
  if (ready == COMPLETED) {
close();
  } else {
LOG.info("{}: sendReply seq={}, {}", name, ready.getSeqNum(), 
ready.getReply());
responseObserver.onNext(
ClientProtoUtils.toRaftClientReplyProto(ready.getReply()));
  }
  }

  @Override
  public void onError(Throwable t) {
// for now we just log a msg
LOG.info(name + ": onError", t);
slidingWindow.close();
  }

  @Override
  public void onCompleted() {
LOG.info("completed request ");
if (slidingWindow.endOfRequests()) {
  close();
}
  }


*Server logs:*

2018-03-08 15:44:06,688 INFO 
org.apache.ratis.grpc.client.RaftClientProtocolService: new 
AppendRequestStreamObserver 127.0.0.1_9858-3

2018-03-08 15:44:06,688 INFO 
org.apache.ratis.grpc.client.RaftClientProtocolService: completed request 



*client code:*

std::shared_ptr< Channel > channel = grpc::CreateChannel(
"localhost:9858",

grpc::InsecureChannelCredentials());

std::unique_ptr stub = 
RaftClientProtocolService::NewStub(channel);

ContainerCommandRequestProto* read_requet = read_container(
"container1");