Re: [grpc-io] C++ service much slower is than Go service.

['Noah Eisen' via grpc.io]

C++ performance is centered around our asynchronous API. If you rewrite the
server/client with that you should see much better performance.

It is a little surprising that the sync API is slower than Go out-of-the
box. We have plans to tune sync API eventually, but for now the focus is on
async

On Sat, Dec 1, 2018 at 8:41 AM  wrote:

> Hi all,
>
> I have been playing around to with gRPC and testing its performance. For
> that I wrote a simple service. The client would send a request containing
> two numbers and a string specifying a math operation. The server would
> perform the math operation and send back the result as response.
>
> I am testing the performance by connecting a single client, opening a
> bidirectional stream, and sending a million requests. I wrote the code for
> it in both Go and C++. The Go server-client is completing the million
> requests-responses in around 3-5 seconds. But in C++, it is taking 25-28
> seconds. Is this supposed to be expected? Or is there something wrong with
> my code? You can take a look at my code at
> github.com/jeet-parekh/grpc-demo. I would appreciate any suggestions for
> improving the performance.
>
> 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/79c25a4b-f72c-47e2-a58f-51ecd0c01d40%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/CAPYwnkgwVj2aiwQcEfpiX-Wj8qxM3v6_ZifxBH26tW29v7p7og%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Announcement: New Custom/Generic Serialization API for gRPC C++ Servers

['Noah Eisen' via grpc.io]

Hi gRPC Users,

*TL;DR*: New API for per-method, generic method handling on the C++ server
side.

*Overview*: Previously, a gRPC C++ server would either be generic, or use
proto specific generated code. Mixing the two was possible, but needed a
lot of hacking. Now, there is an option to mark a single method as *Raw*.
This signifies to the generated code that the server should handle the
method in terms of ByteBuffer, not in terms of the protobuf objects. This
can be useful to special case the serialization for critical methods.

More details can be found in these two gRFCs:

   - Exposing GrpcProtoBuffer{Reader|Writer}:
   L25-expose-buffer-reader-writer.md
   

   - C++ Raw API: L26-cpp-raw-codegen-api.md
   


The implementation (along with example usage in the tests) can be found in:

   - Exposing GrpcProtoBuffer{Reader|Writer}: #14541
   
   - C++ Raw API: #15771 

-- 
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/CAPYwnkgY%3D7MjF1AsrrCXc66mW-O3qOGejG8M4inREaqOXKX__A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] gRPC c++ async server vs sync server

['Noah Eisen' via grpc.io]

The async model give the application code full control over threading. Sync
can handle multiple requests in parallel, yes, but they are serviced from a
gRPC thread pool.

If you want finer control over threading, then async is the better model to
use

On Thu, Aug 16, 2018 at 12:27 AM  wrote:

> I new to gRPC. I don't get the differences between sync and async server.
>
> In gRPC C++ example on [github][2]. The distinction in async and sync
> isn't obvious.
>
> - According to this [question][1] and with my test, sync gRPC server can
> handle parallele request.
> - And in the asynchronous example the `server.Run();` is blocking.
>
> So What's the difference between both ?
>
>   [1]:
> https://stackoverflow.com/questions/45486733/simultaneous-grpc-clients-sync-async-server
>   [2]:https://github.com/grpc/grpc/tree/master/examples/cpp/helloworld
>
> --
> 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/f030c64c-18b1-402a-bd01-5e7edbcaf16f%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/CAPYwnkhdEVxfLzGrP-x6Z2zLmzZVM0FiJFe%2BEAGmOqS6JgMLKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: gRFC A14 Channelz Service

['Noah Eisen' via grpc.io]

Support for channelz in c core is ongoing. See
https://github.com/grpc/grpc/issues/15340 for tracking

On Mon, May 21, 2018 at 3:52 PM Arpit Baldeva  wrote:

> Hi,
>
> Can you comment on the status of the C/C++ port? I searched on the forum
> for recent conversations but nothing useful turned up.
>
> Thanks.
>
> On Monday, February 5, 2018 at 2:32:25 PM UTC-8, Carl Mastrangelo wrote:
>>
>> This has been merged, and is being implemented actively in Java and Go,
>> and soon by C.
>>
>> On Wednesday, October 11, 2017 at 6:34:53 PM UTC-7, Carl Mastrangelo
>> wrote:
>>>
>>> Here is a temporary link to my repo which has proper markdown:
>>> https://github.com/carl-mastrangelo/proposal/blob/4f5f266134836189fbda84d564e32dc7315c49e6/A14-channelz.md
>>>
>>> On Wednesday, October 11, 2017 at 6:34:07 PM UTC-7, Carl Mastrangelo
>>> wrote:

 Hi all,

 Channelz is an advanced debugging interface that allows you to remotely
 query a server or client and find out implementation details about its
 channels.  Any feedback is welcome!

 https://github.com/grpc/proposal/pull/40


 Feedback is appreciated. Per the gRFC process, please keep discussion
 in this thread.

>>> --
> 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/ab26d21e-29db-4fd4-936d-b0612326f4e9%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/CAPYwnkhi1GMoaHfemPBS46khCaNcYrMEHQ1SnBN7efpAcujGKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] [grpc c++] Stream buffer writting policy

['Noah Eisen' via grpc.io]

In that case, this is something that you will have to handle in application
logic. gRPC bidi streams to not have ack mechanisms per-message

On Wed, May 16, 2018 at 6:56 AM David Audrain 
wrote:

> Attached is the log generated with grpc v1.11.1 .
>
> My test application looks to behave the same way.
>
> Everything looks fine from a grpc API perspective after the wifi
> connection is being turned off around 9h34m35s.
> Wifi connection is turned on around 9h37m00s and test application
> processes messages from the backend around 9h37m29s.
>
>
>
>
> On Tuesday, May 15, 2018 at 7:21:12 PM UTC-4, Noah Eisen wrote:
>>
>> Ok, let me know if things change with 1.11.
>>
>> But as I said, if gRPC client does not notice anything wrong with the TCP
>> connection, it has no way to report failures.
>>
>> The server would be responsible for noticing the missing data and closing
>> the stream accordingly
>>
>> On Tue, May 15, 2018 at 3:28 PM David Audrain 
>> wrote:
>>
>>> v1.7.1
>>>
>>> I am in the process of using v1.11.1
>>>
>>> On Tuesday, May 15, 2018 at 5:18:07 PM UTC-4, Noah Eisen wrote:

 These log statements are quite old... what version of gRPC are
 you using?

 On Tue, May 15, 2018 at 1:20 PM David Audrain 
 wrote:

> Please find a debug.log generated by GRPC C++ 1.7.1
>
> Wifi connection has been turned off between I0515 16:06:35 and
> 16:07:40.
>
> GRPC_ARG_HTTP2_WRITE_BUFFER_SIZE is set to 64
>
> On Tuesday, May 15, 2018 at 11:38:03 AM UTC-4, Noah Eisen wrote:
>>
>> I am not familiar with how a Mac handles network change like that.
>>
>> Can you re run this case with more verbose tracing turned on?
>>
>> export GRPC_TRACE=call_error,http,api
>> export GRPC_VERBOSITY=debug
>>
>> If the client isn't seeing any strangeness when it gets to sending
>> the bytes, then there is nothing to do here. gRPC does not have a built 
>> in
>> mechanism for messages in a long lives stream to be ack-ed. I would 
>> suggest
>> adding something to your service as a sanity check that all messages came
>> through. Seems like even a dumb incremental counter might work.
>>
>> On Mon, May 14, 2018 at 7:47 PM David Audrain 
>> wrote:
>>
>>> "Network connection is turned off at time T" would be like turning
>>> Wi-Fi off on a Mac while client is writing messages on a client 
>>> streaming
>>> service.
>>>
>>> --
>>> 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/1a42aec9-80a0-4b54-9ad0-ae8e98619e7f%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/0db25e69-8c08-4447-b343-b400c345f8d0%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/4bec5fdf-e981-4219-8830-345c8e818dc0%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 

Re: [grpc-io] [grpc c++] Stream buffer writting policy

['Noah Eisen' via grpc.io]

Ok, let me know if things change with 1.11.

But as I said, if gRPC client does not notice anything wrong with the TCP
connection, it has no way to report failures.

The server would be responsible for noticing the missing data and closing
the stream accordingly

On Tue, May 15, 2018 at 3:28 PM David Audrain 
wrote:

> v1.7.1
>
> I am in the process of using v1.11.1
>
> On Tuesday, May 15, 2018 at 5:18:07 PM UTC-4, Noah Eisen wrote:
>>
>> These log statements are quite old... what version of gRPC are you using?
>>
>> On Tue, May 15, 2018 at 1:20 PM David Audrain 
>> wrote:
>>
>>> Please find a debug.log generated by GRPC C++ 1.7.1
>>>
>>> Wifi connection has been turned off between I0515 16:06:35 and 16:07:40.
>>>
>>> GRPC_ARG_HTTP2_WRITE_BUFFER_SIZE is set to 64
>>>
>>> On Tuesday, May 15, 2018 at 11:38:03 AM UTC-4, Noah Eisen wrote:

 I am not familiar with how a Mac handles network change like that.

 Can you re run this case with more verbose tracing turned on?

 export GRPC_TRACE=call_error,http,api
 export GRPC_VERBOSITY=debug

 If the client isn't seeing any strangeness when it gets to sending the
 bytes, then there is nothing to do here. gRPC does not have a built in
 mechanism for messages in a long lives stream to be ack-ed. I would suggest
 adding something to your service as a sanity check that all messages came
 through. Seems like even a dumb incremental counter might work.

 On Mon, May 14, 2018 at 7:47 PM David Audrain 
 wrote:

> "Network connection is turned off at time T" would be like turning
> Wi-Fi off on a Mac while client is writing messages on a client streaming
> service.
>
> --
> 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/1a42aec9-80a0-4b54-9ad0-ae8e98619e7f%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/0db25e69-8c08-4447-b343-b400c345f8d0%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/4bec5fdf-e981-4219-8830-345c8e818dc0%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/CAPYwnkgJgdmhRXdeCzNM_hC%2BQy-%3D6mBBK%2Bm4mAmW_0tjwBK7YQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] [grpc c++] Stream buffer writting policy

['Noah Eisen' via grpc.io]

These log statements are quite old... what version of gRPC are you using?

On Tue, May 15, 2018 at 1:20 PM David Audrain 
wrote:

> Please find a debug.log generated by GRPC C++ 1.7.1
>
> Wifi connection has been turned off between I0515 16:06:35 and 16:07:40.
>
> GRPC_ARG_HTTP2_WRITE_BUFFER_SIZE is set to 64
>
> On Tuesday, May 15, 2018 at 11:38:03 AM UTC-4, Noah Eisen wrote:
>>
>> I am not familiar with how a Mac handles network change like that.
>>
>> Can you re run this case with more verbose tracing turned on?
>>
>> export GRPC_TRACE=call_error,http,api
>> export GRPC_VERBOSITY=debug
>>
>> If the client isn't seeing any strangeness when it gets to sending the
>> bytes, then there is nothing to do here. gRPC does not have a built in
>> mechanism for messages in a long lives stream to be ack-ed. I would suggest
>> adding something to your service as a sanity check that all messages came
>> through. Seems like even a dumb incremental counter might work.
>>
>> On Mon, May 14, 2018 at 7:47 PM David Audrain 
>> wrote:
>>
>>> "Network connection is turned off at time T" would be like turning Wi-Fi
>>> off on a Mac while client is writing messages on a client streaming service.
>>>
>>> --
>>> 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/1a42aec9-80a0-4b54-9ad0-ae8e98619e7f%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/0db25e69-8c08-4447-b343-b400c345f8d0%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/CAPYwnkgyx6tBwHc%2BQvHgi5dhu_AbLWNe7LuUaZDY6UC43%2Bw9mA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] [grpc c++] Stream buffer writting policy

['Noah Eisen' via grpc.io]

I am not familiar with how a Mac handles network change like that.

Can you re run this case with more verbose tracing turned on?

export GRPC_TRACE=call_error,http,api
export GRPC_VERBOSITY=debug

If the client isn't seeing any strangeness when it gets to sending the
bytes, then there is nothing to do here. gRPC does not have a built in
mechanism for messages in a long lives stream to be ack-ed. I would suggest
adding something to your service as a sanity check that all messages came
through. Seems like even a dumb incremental counter might work.

On Mon, May 14, 2018 at 7:47 PM David Audrain 
wrote:

> "Network connection is turned off at time T" would be like turning Wi-Fi
> off on a Mac while client is writing messages on a client streaming service.
>
> --
> 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/1a42aec9-80a0-4b54-9ad0-ae8e98619e7f%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/CAPYwnki0nDncHCbxaL03bB3fr1vMxmJpqoU7rFL578D%3D%2BELmcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] [grpc c++] Stream buffer writting policy

['Noah Eisen' via grpc.io]

Can you elaborate on what you mean by "Network connection is turned off at
time T"? If the underlying TCP connection is broken, then the client should
definitely notice something is wrong in that dark minute...

On Mon, May 14, 2018 at 2:15 PM David Audrain 
wrote:

> Hi,
>
> I am doing some testing between a client and a server to understand how
> GRPC C++ buffers messages being written to a RPC stream when the network
> connection is switched off.
>
> GRPC_ARG_HTTP2_WRITE_BUFFER_SIZE is set to 64 bytes when creating the
> channel, and each message written to the stream is 52 bytes large.
>
> Steps are the following:
>
>- Start server and client
>- Client creates a channel with no keep alive and
>GRPC_ARG_HTTP2_WRITE_BUFFER_SIZE is set to 64 bytes
>- Client writes 52 bytes large message every 5 seconds, server logs
>each message received
>- Network connection is turned off at time T
>- Client keeps writing 52 bytes large message every 5 seconds,
>WriterInterface::Write keeps returning true.
>- Network connection is turned on at time T + 1 minute
>- Clients continues  writing 52 bytes large message every 5 seconds,
>Server logs the message written around time T and messages written after T
>+ 1 minute
>
> As expected only one message has been buffered by GRPC library.
>
> However it is the first message being written after the network connection
> has been turned off and subsequent writing operations did not escalate any
> error saying that written messages were lost.
>
> Is there any API that would notify about such situation?
>
> Thank you,
> David
>
> --
> 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/483d654c-0654-4fc1-8612-f929820e9f85%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/CAPYwnkgz_47LQFhE2%2Biz_uErUQUOrFgRzUXa3Lur80XEHimZpw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: [C++] How to simulate GO tls config InsecureSkipVerify

['Noah Eisen' via grpc.io]

I am linking in Eric (ej...@google.com)

Looks like #3992  added the
example of generating credentials. Any input on why that won't work for a
C++ TLS greeter service (copying the github creds will work)

On Wed, Apr 4, 2018 at 2:02 PM David Audrain 
wrote:

> I've implemented a tls version of helloworld/greeter_client
> 
> and server
> 
> .
>
> First test case (failing one)
>
> Then I followed theses steps
> 
> to create certificate, keys, etc...
>
> greeter_tls_server is run
> ~/sources/github.com/grpc/grpc/examples/cpp/helloworld$ ./greeter_tls_server
> localhost 50051 ca.crt server.crt server.key
>
> greeter_tls_client is run
> ~/sources/github.com/grpc/grpc/examples/cpp/helloworld$ ./greeter_tls_client
> localhost 50051 localhost ca.crt
>
> greeter_tls_client fails
> SSL target name override : SET TO [localhost]
> E0404 16:43:27.918287000 140735524692800 ssl_transport_security.cc:1063]
> Handshake failed with fatal error SSL_ERROR_SSL: error:107d:SSL
> routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.
> E0404 16:43:27.933634000 140735524692800 ssl_transport_security.cc:1063]
> Handshake failed with fatal error SSL_ERROR_SSL: error:107d:SSL
> routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.
> 14: Connect Failed
> Greeter TLS received: RPC failed
>
> Java HelloWorldTlsClient from grpc-java succeeds:
> ~/sources/github.com/grpc/grpc-java/examples$ ./build/install/examples/bin
> /hello-world-tls-client localhost 50051 ca.crt
> Apr 04, 2018 4:40:52 PM io.grpc.examples.helloworldtls.HelloWorldClientTls
> greet
> INFO: Will try to greet localhost ...
> Apr 04, 2018 4:40:52 PM io.grpc.examples.helloworldtls.HelloWorldClientTls
> greet
> INFO: Greeting: TLS Hello localhost
>
> Second test case (success)
>
> The grpc repository contains certificate and keys generated in
> src/core/tsi/test_creds
> . (BTW
> I've not been able to regenerate theses files myself following the provided
> README
> )
>
> This second test case uses the credentials of grpc repository.
>
> greeter_tls_server:
> ~/sources/github.com/grpc/grpc/examples/cpp/helloworld$ ./greeter_tls_server
> localhost 50051 ../../../src/core/tsi/test_creds/ca.pem ../../../src/core/
> tsi/test_creds/server0.pem ../../../src/core/tsi/test_creds/server0.key
>
> greeter_tls_client succeeds:
> ~/sources/github.com/grpc/grpc/examples/cpp/helloworld$ ./greeter_tls_client
> localhost 50051 foo.test.google.com.au ../../../src/core/tsi/test_creds/ca
> .pem
> SSL target name override : SET TO [foo.test.google.com.au]
>
> Greeter TLS received: TLS Hello world
>
>
> Java HelloWorldTlsClient fails (I guess the domain *.test.google.com.au
> should be specified somewhere)
> Apr 04, 2018 4:54:10 PM io.grpc.examples.helloworldtls.HelloWorldClientTls
> greet
> INFO: Will try to greet localhost ...
> Apr 04, 2018 4:54:10 PM io.grpc.examples.helloworldtls.HelloWorldClientTls
> greet
> WARNING: RPC failed: Status{code=UNAVAILABLE, description=io exception,
> cause=javax.net.ssl.SSLHandshakeException: General OpenSslEngine problem
>  at io.netty.handler.ssl.
> ReferenceCountedOpenSslContext$AbstractCertificateVerifier.verify(
> ReferenceCountedOpenSslContext.java:634)
> 
> Caused by: java.security.cert.CertificateException: No name matching
> localhost found
>  at sun.security.util.HostnameChecker.matchDNS(HostnameChecker.java:221)
>
>
>
> Conclusion : Using the credentials from the grpc repository,
> greeter_tls_client works ok against greeter_tls_server.
>
> Questions : What is wrong with the credentials generation provided on the 
> grpc-java
> example README
> 
> ?
>
>
> On Wednesday, April 4, 2018 at 1:33:03 PM UTC-4, ncte...@google.com wrote:
>
>> That seems like the right way to go about it.
>>
>> Are you running into trouble? what are the errors?
>>
>> On Thursday, March 29, 2018 at 3:36:59 PM UTC-7, David Audrain wrote:
>>>
>>> Hi,
>>>
>>> My C++ Client tries to connect my dev server using TLS but connection
>>> keeps failing while checking the dev server certificate.
>>>
>>> The go version uses the following workaround to skip the verification:
>>>
>>> grpcOpts := []grpc.DialOption{}
>>> creds := credentials.NewTLS({InsecureSkipVerify: *
>>> insecureSkipVerify})
>>> grpcOpts = append(grpcOpts, grpc.WithTransportCredentials(creds))
>>>
>>> What is the equivalent with C++ GRPC library?

Re: [grpc-io] Re: gRPC as a managed service in GCP

['Noah Eisen' via grpc.io]

I do know know that. Ken has had more experience with App Engine, linking
him in.

On Wed, Apr 4, 2018 at 1:03 PM Ofer Bartal  wrote:

> Thanks!
> Do you know of any end-to-end working example of gRPC on App Engine Flex?
>
> On Wed, Apr 4, 2018 at 8:51 PM ncteisen via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> Ahh sorry, I may have misinterpreted your question.
>>
>> I would suggest looking into app engine flex
>> 
>>
>>
>> On Wednesday, April 4, 2018 at 7:07:16 AM UTC-7, of...@google.com wrote:
>>
>>> Hi,
>>> I'm interested in using gRPC as a managed service in GCP.
>>> Do you know of such a service in GCP?
>>>
>>> Thanks!
>>> Ofer
>>>
>> --
>> 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/nRIAcx4jwKU/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/847c9b35-84b7-44a1-b013-545492659f99%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/CAPYwnkh%3Di_umauoxK6wkp2sME%3DsyvQmCmN97M7yjHFkLmZdtcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: What is the behaviour of grpc::ServerContext::IsCancelled()

['Noah Eisen' via grpc.io]

Can you give a little more info about your use case? What exact information
do you need, and in what situations?

I agree that digging into the non-public structs is a bad idea, since we
maybe change those from time to time. If you present a use case that is
lacking from our public API, we can add some new methods to ServerContext
to expose more details

On Thu, Apr 5, 2018 at 1:10 AM Okke Hendriks  wrote:

> Thank you,
>
> Indeed it seems to be the case that it is more like IsFailed() instead of
> IsCanceled().
>
> If i examine the *grpc_call*
> 
> struct, (accessible through the c++ API
> ,
> but using it will require including non-public core lib headers? Which i do
> not want to do.) it has an *grpc_call_final_info* member defined here
> 
> .
> Which includes a *grpc_status_code*  and error message, I do not know if
> these are set on the server side, but this might be something to expose on
> the C/C++ API?
>
>
> On Wednesday, April 4, 2018 at 7:25:14 PM UTC+2, ncte...@google.com wrote:
>>
>> Taking a look at the C API, it looks like IsCancelled() will be true "if
>> the call failed in any way". See here
>> 
>> .
>>
>> There is not an API method to determine more info about error, but that
>> should be available by examining logs. (setting GRPC_VERBOSITY=debug and
>> GRPC_TRACE=all)
>>
>> On Wednesday, March 28, 2018 at 11:45:36 AM UTC-7, Okke Hendriks wrote:
>>>
>>> Hello,
>>>
>>> I am using the sync grpc C++ API v1.10.0.
>>>
>>> Could someone explain to me what the exact behaviour of IsCancelled()
>>> 
>>>  is?
>>>
>>> Does it evaluate to true if and only if the client sends a TryCancel()
>>> which was received by the server?
>>> Or also if a call/stream closed due to another reason (socket closed, OS
>>> error, etc.)?
>>>
>>> If it is NOT the case that it only returns true when a client cancelled,
>>> is there a way to find the reason of the cancellation, aka the status?
>>>
>>> Kind regards,
>>>
>>> Okke Hendriks
>>>
>> --
> 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/505433e8-0b74-44f0-9895-d097a240b786%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/CAPYwnkgR2BgXGRKqPBWJskJSX55LorFK5GA%2B0BgX%3D0%3Dzhv_W0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Multi-hop gRPC benchmark

['Noah Eisen' via grpc.io]

I have a correction to my previous answer.

All languages do support the same benchmarking design, so they can interop
with each other. Picking one example, here is Ruby's implementation of the qps
service . So any
combination of client and server can be benchmarked.

This means, jumping back to your original question, that proxy support
would have to be added to all of the languages qps benchmark services


On Wed, Mar 21, 2018 at 4:55 AM Noah Eisen  wrote:

> This only applies to the cpp benchmarks. I am not very familiar with the
> other language though, so they might have a similar architecture, but all
> benchmarks are one language. We don't benchmark scenarios like a go client
> talking to a cpp server yet.
>
>
> On Tue, Mar 20, 2018 at 10:15 PM Thomas Ramfjord 
> wrote:
>
>> Would this just apply to the cpp benchmarks?  Or do all of the benchmarks
>> communicate with a cpp server already? Thanks for all of the assistance
>> you've already given.
>>
>>
>>
>> *From: *Noah Eisen 
>> *Date: *Tuesday, March 20, 2018 at 7:40 AM
>> *To: *Nan Dun 
>> *Cc: *"grpc.io" , Thomas Ramfjord <
>> tramfj...@quantcast.com>
>> *Subject: *Re: [grpc-io] Multi-hop gRPC benchmark
>>
>>
>>
>> We do not have this functionality at the moment.
>>
>>
>>
>> We welcome external contributions if you would like to take a stab at it.
>> I think you could use the proto, as is, and then add a new type of Worker
>> called Proxy (currently a Worker can be either a Client or a Server). In
>> the simplest case you would have three workers, and the test driver would
>> tell one to become client, one to become server, and one to become proxy.
>>
>>
>>
>> All the code for that lives here:
>> https://github.com/grpc/grpc/tree/master/test/cpp/qps
>>
>>
>>
>> On Tue, Mar 20, 2018 at 4:42 AM Nan Dun  wrote:
>>
>> Hi,
>>
>>
>>
>> Is there a simple way to run or extend gRPC performance benchmark (
>> https://grpc.io/docs/guides/benchmarking.html) in a multi-hop way
>> instead of current peer-to-peer ping pong? For example, we have three
>> servers, A, B, C: A calls B, and then B calls C.
>>
>>
>>
>> Probably just extend the interface
>> https://github.com/grpc/grpc/blob/master/src/proto/grpc/testing/services.proto
>> to implement a service to relay the calls?
>>
>>
>>
>> Thanks!
>>
>> - 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/55A41C99-16B4-4073-B4BE-2343E747FDB9%40quantcast.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/CAPYwnkgiDMDvxjQ15cTFmg934qv8GpPsv1ZWvMG1KBL5ZeHLHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Multi-hop gRPC benchmark

['Noah Eisen' via grpc.io]

This only applies to the cpp benchmarks. I am not very familiar with the
other language though, so they might have a similar architecture, but all
benchmarks are one language. We don't benchmark scenarios like a go client
talking to a cpp server yet.


On Tue, Mar 20, 2018 at 10:15 PM Thomas Ramfjord 
wrote:

> Would this just apply to the cpp benchmarks?  Or do all of the benchmarks
> communicate with a cpp server already? Thanks for all of the assistance
> you've already given.
>
>
>
> *From: *Noah Eisen 
> *Date: *Tuesday, March 20, 2018 at 7:40 AM
> *To: *Nan Dun 
> *Cc: *"grpc.io" , Thomas Ramfjord <
> tramfj...@quantcast.com>
> *Subject: *Re: [grpc-io] Multi-hop gRPC benchmark
>
>
>
> We do not have this functionality at the moment.
>
>
>
> We welcome external contributions if you would like to take a stab at it.
> I think you could use the proto, as is, and then add a new type of Worker
> called Proxy (currently a Worker can be either a Client or a Server). In
> the simplest case you would have three workers, and the test driver would
> tell one to become client, one to become server, and one to become proxy.
>
>
>
> All the code for that lives here:
> https://github.com/grpc/grpc/tree/master/test/cpp/qps
>
>
>
> On Tue, Mar 20, 2018 at 4:42 AM Nan Dun  wrote:
>
> Hi,
>
>
>
> Is there a simple way to run or extend gRPC performance benchmark (
> https://grpc.io/docs/guides/benchmarking.html) in a multi-hop way instead
> of current peer-to-peer ping pong? For example, we have three servers, A,
> B, C: A calls B, and then B calls C.
>
>
>
> Probably just extend the interface
> https://github.com/grpc/grpc/blob/master/src/proto/grpc/testing/services.proto
> to implement a service to relay the calls?
>
>
>
> Thanks!
>
> - 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/55A41C99-16B4-4073-B4BE-2343E747FDB9%40quantcast.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/CAPYwnkiJ-2nMJJBBmCNTs%2BZCe98F0ExGkPpeE7rWNSRvA0YBDw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Multi-hop gRPC benchmark

['Noah Eisen' via grpc.io]

We do not have this functionality at the moment.

We welcome external contributions if you would like to take a stab at it. I
think you could use the proto, as is, and then add a new type of Worker
called Proxy (currently a Worker can be either a Client or a Server). In
the simplest case you would have three workers, and the test driver would
tell one to become client, one to become server, and one to become proxy.

All the code for that lives here:
https://github.com/grpc/grpc/tree/master/test/cpp/qps


On Tue, Mar 20, 2018 at 4:42 AM Nan Dun  wrote:

> Hi,
>
>
>
> Is there a simple way to run or extend gRPC performance benchmark (
> https://grpc.io/docs/guides/benchmarking.html) in a multi-hop way instead
> of current peer-to-peer ping pong? For example, we have three servers, A,
> B, C: A calls B, and then B calls C.
>
>
>
> Probably just extend the interface
> https://github.com/grpc/grpc/blob/master/src/proto/grpc/testing/services.proto
> to implement a service to relay the calls?
>
>
>
> Thanks!
>
> - 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/55A41C99-16B4-4073-B4BE-2343E747FDB9%40quantcast.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/CAPYwnkgH7n35gSOvA-Pz0ccLGzosctjg2eY-RX%3Dz%3DwYyfPGEdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] [grpc][c++] When will grpc c++ support zero copy?

['Noah Eisen' via grpc.io]

Can you be more specific? Zero copy of what data to where?

On Mon, Nov 6, 2017 at 6:18 PM, yihao yang  wrote:

> Hi, all
>
> Does grpc c++ or core support zero copy? Is there any plan?
>
> Thank,
> Yihao
>
> --
> 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/e711e79a-5501-4d99-a999-52cadbdcb0e4%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/CAPYwnkjtfL%3D2wQ70E6ivic%2BmY7uFMRddtA%2BxvogXDKg1xtgEPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: [grpc-c++] How to change HTTP/2 default window size?

['Noah Eisen' via grpc.io]

Hi,

Flow control is very intrinsic to all http2 behavior, so it very well could
have throughput implications. gRPC's transport layer does a lot of
automatic tuning of flow control values based on BDP estimate. However,
these numbers take time to settle, so if you are benchmarking, ensure you
have a sufficient warm up period before starting measurements.

If you do want to make manual changes, you can tune the initial window size
by setting the channel arg GRPC_ARG_HTTP2_STREAM_LOOKAHEAD_BYTES, which is
found here

.

Hope this helps,
Noah



On Mon, Nov 6, 2017 at 6:17 PM, yihao yang  wrote:

> Could any one help?
>
> 在 2017年10月13日星期五 UTC-7下午1:09:17，yihao yang写道：
>>
>> Hi, all
>>
>> I wonder if the window size will affect the throughput of unary RPCs.
>> And how to configure the window size in GRPC?
>>
>> Thanks,
>> Yihao
>>
> --
> 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/2ecf634b-9bb5-4dd0-b2c5-f35e6e577109%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/CAPYwnkhpU-CCPur%2BONAbLTsJ2FTmAkDjkz_wquCpxo3ru5oTmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] streams and ordering

['Noah Eisen' via grpc.io]

The messages will be delivered in order for client streaming and server
streaming. They are actually just special cases of bidi streaming, which as
the tutorial mentions, are delivered in order. Unary RPCs are actually also
just a special cases of bidi streaming, because in gRPC, everything is
streaming!

On Tue, Oct 24, 2017 at 4:52 PM, 'Anshul Pundir' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hi,
>
> It is not clear from the offcial grpc tutorial here
>  whether messages are
> delivered in order for client or server side streaming. Can someone clarify
> this please ?
>
> Note that the tutorial does mention that messages are delivered in order
> for bi-directional streams.
>
> Thanks!
> Anshul
>
> --
> 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/CADzhs8HCensbtdz7HV-Gk86YX-AQooHGqza9wvv4VP0TRWcy7g%
> 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/CAPYwnkgvxzSwijodkmjrjMg-vVY-AeosjJFF3Hhk_DJgu7ReCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] [Newbie question] The confusion about direct make and using cmake to build grpc

['Noah Eisen' via grpc.io]

TL;DR: No, there should be no difference.

Longer answer:

Believe it or not there is a third way! We also support building with Bazel
.

Makefile and Bazel are both official supported. CMake exists, and we
maintain it, but there is no obligation that it will stay up to date. So I
would suggest sticking to Bazel or Make.

On Tue, Aug 29, 2017 at 1:27 AM,  wrote:

> Hi all,
>
> Greetings from me! I am a newbie of grpc, and a little confused about
> building.
>
> From build from source
> ,
> I check the compiling is like this:
>
> $ cd grpc
> $ git submodule update --init
> $ make
>
>
> But I also find CMakeLists.txt in the root directory. So I try the
> following "standard" cmake build flow:
>
> $ cd grpc
> $ mkdir build
> $ cd build
> $ cmake ..
> $ make
>
> It also works.
>
> So could anyone help to explain the difference between these 2 kinds of
> building flow?
>
> Thanks very much in advance!
>
> Best Regards
> Nan Xiao
>
> --
> 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/156c693c-1e5a-4301-ae4d-4295588fe20f%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/CAPYwnkgetDrsz68suL2j78G7zTXQnGeKHbosVN4McdzZ%3DyYY-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] gRPC throughput

['Noah Eisen' via grpc.io]

Check out the QPS Driver code:
https://github.com/grpc/grpc/tree/master/test/cpp/qps

make qps_json_driver

Then you can run different scenarios by invoking bins/opt/qps_json_driver
--scenarios_json 

A scenario that might work well for you would be:

 '{"scenarios":[{"spawn_local_worker_count":-6,"name":"generated",
"warmup_seconds": 30, "benchmark_seconds": 120, "num_servers": 1,
"server_config": {"async_server_threads": 31, "security_params": null,
"server_type": "ASYNC_SERVER"}, "num_clients": 5, "client_config":
{"client_type": "ASYNC_CLIENT", "security_params": null, "payload_config":
{"simple_params": {"resp_size": 1024, "req_size": 1024}},
"client_channels": 31, "async_client_threads": 31,
"outstanding_rpcs_per_channel": 100, "rpc_type": "UNARY", "load_params":
{"closed_loop": {}}, "histogram_params": {"max_possible": 600.0,
"resolution": 0.01}}}]}'

That involves 5 clients being served by a single server. But you can play
around with all of the above knobs

On Tue, Jul 25, 2017 at 11:52 AM, Rajarshi Biswas <
rajarshibiswa...@gmail.com> wrote:

> Hi,
>
> I am trying to evaluate gRPC performance in a cluster. Is there any
> benchmarks available that I can use to measure throughput when multiple
> clients are served by a single server?
>
> Thank you
>
> Rajarshi
>
> --
> 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/15687115-7c5f-483d-96d6-5c215a419332%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/CAPYwnkjOgVr39Un9VTR0Qbprk_edXMyyyZSeWnk4ds0NG4F8Fw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Why grpc channel choose to use exponential backoff algorithm?

['Noah Eisen' via grpc.io]

Hi Yihao

We expose the following knobs to configure channel reconnect:
INITIAL_BACKOFF, MULTIPLIER, JITTER, MAX_BACKOFF, MIN_CONNECT_TIMEOUT. Most
of those can be set via channel args (some , like jitter, have to be hard
coded, but a PR to change them to channel args should be trivia).

If that does not give you enough control, then you can set wait_for_ready
to false (see here
), and
implement custom reconnect logic there.

BEst,
Noah

On Fri, Jul 14, 2017 at 11:13 AM, yihao yang 
wrote:

> https://github.com/grpc/grpc/blob/master/doc/connection-backoff.md
>
> Hi,
>
> Can any one talk about why using exponential backoff when reconnecting?
> Seems I cannot costume my own reconnect algorithms outside. I can only
> recreate a new channel based on some stragety.
>
> Thanks,
> Yihao
>
> --
> 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/bb814336-6c46-4ab5-ac40-51688d0a2a4a%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/CAPYwnkhY24e%2Bnz5a6QzWLe0nDm2Otwq3ixyy2w9uwi2ThAs3gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Unexpected grpc verbose messages

['Noah Eisen' via grpc.io]

Fixing PR at https://github.com/grpc/grpc/pull/11770

On Wed, Jul 12, 2017 at 7:10 AM, Noah Eisen  wrote:

> Ok, I can also repro this pretty easily on my Linux box, and my MacOS
> laptop. Might be an issue with when the c core checks the GRPC_VERBOSITY
> environment variable. I'll look into it this morning.
>
> On Tue, Jul 11, 2017 at 11:04 PM, 'Julien' via grpc.io <
> grpc-io@googlegroups.com> wrote:
>
>> Hello,
>>
>> System is Red Hat Enterprise Linux 6.6, with kernel
>> 2.6.32-642.13.1.el6.x86_64 and gcc 5.2.0.
>>
>> Regards,
>>
>> Julien
>>
>>
>> Le mercredi 12 juillet 2017 00:52:05 UTC+2, ncte...@google.com a écrit :
>>>
>>> What OS are you running on? I will try to repro and look into this
>>>
>>> On Monday, July 3, 2017 at 12:30:38 AM UTC-7, Julien wrote:

 Any comment on this?

 Thanks.

 Julien


 Le jeudi 29 juin 2017 16:04:55 UTC+2, Julien a écrit :
>
> Hello,
>
> Several unexpected info and debug messages are displayed when I start
> and when I stop the server.
> These messages appear whatever the value of the GRPC_VERBOSITY
> variable.
> For example:
> % export GRPC_VERBOSITY=ERROR
>
> % server start
> I0629 15:18:44.6752094779291 server_builder.cc:262]
> Synchronous server. Num CQs: 32, Min pollers: 1, Max Pollers: 2, CQ
> timeout (msec): 1
> D0629 15:18:44.6752819639291 env_linux.c:77] Warning:
> insecure environment read function 'getenv' used
>
> % server stop
> D0629 15:18:57.5530231059421 env_linux.c:77] Warning:
> insecure environment read function 'getenv' used
>
>
> I tried with grpc 1.1.4 and 1.4.0: the messages are displayed whatever
> the version.
>
> Am I doing something wrong? Or is this a bug?
> Is there a way to get rid of these messages?
>
> Thanks.
>
> Julien
>
 --
>> 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/ms
>> gid/grpc-io/542aa5ef-c098-4ac4-a5e5-7923260013f5%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/CAPYwnkgnyYSXDcMgUZA7GX_qA31eXY9HeKay9ruTYvc68w%2BSpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Unexpected grpc verbose messages

['Noah Eisen' via grpc.io]

Ok, I can also repro this pretty easily on my Linux box, and my MacOS
laptop. Might be an issue with when the c core checks the GRPC_VERBOSITY
environment variable. I'll look into it this morning.

On Tue, Jul 11, 2017 at 11:04 PM, 'Julien' via grpc.io <
grpc-io@googlegroups.com> wrote:

> Hello,
>
> System is Red Hat Enterprise Linux 6.6, with kernel
> 2.6.32-642.13.1.el6.x86_64 and gcc 5.2.0.
>
> Regards,
>
> Julien
>
>
> Le mercredi 12 juillet 2017 00:52:05 UTC+2, ncte...@google.com a écrit :
>>
>> What OS are you running on? I will try to repro and look into this
>>
>> On Monday, July 3, 2017 at 12:30:38 AM UTC-7, Julien wrote:
>>>
>>> Any comment on this?
>>>
>>> Thanks.
>>>
>>> Julien
>>>
>>>
>>> Le jeudi 29 juin 2017 16:04:55 UTC+2, Julien a écrit :

 Hello,

 Several unexpected info and debug messages are displayed when I start
 and when I stop the server.
 These messages appear whatever the value of the GRPC_VERBOSITY variable.
 For example:
 % export GRPC_VERBOSITY=ERROR

 % server start
 I0629 15:18:44.6752094779291 server_builder.cc:262]
 Synchronous server. Num CQs: 32, Min pollers: 1, Max Pollers: 2, CQ
 timeout (msec): 1
 D0629 15:18:44.6752819639291 env_linux.c:77] Warning:
 insecure environment read function 'getenv' used

 % server stop
 D0629 15:18:57.5530231059421 env_linux.c:77] Warning:
 insecure environment read function 'getenv' used


 I tried with grpc 1.1.4 and 1.4.0: the messages are displayed whatever
 the version.

 Am I doing something wrong? Or is this a bug?
 Is there a way to get rid of these messages?

 Thanks.

 Julien

>>> --
> 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/542aa5ef-c098-4ac4-a5e5-7923260013f5%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/CAPYwnkg8nwp0O9%3DK8a6HxDzPAQzAWuwAoZz%2BSZAUNaxZm6tH0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Grpc Client-side C++ Channel Destructor taking 10 seconds

['Noah Eisen' via grpc.io]

Could you turn on debugging and attach the output? I have a hunch that this
comes from grpc_iomgr_shutdown. It will wait ten seconds to try to free all
iomgr object before giving up and leaking memory.

export GRPC_VERBOSITY=DEBUG for minimal debugging. That should be enough,
but for even more trace you can do export GRPC_TRACE=all

On Mon, May 29, 2017 at 12:12 PM, Veldaeven  wrote:

> The purpose of the code was initially to test the operation of the grpc
> stub when the grpc service was not available. However, the behavior I'm
> seeing indicates that there's something going on that I don't understand-
> hence the question.
>
> In this code:
>
> #define IN_MILLISECONDS(x) (std::chrono::system_clock::now() + std::
> chrono::milliseconds(x))
>
> string NowString()
> {
> char buf[128];
> SYSTEMTIME timeBuf;
> ::GetLocalTime();
> sprintf(buf, "%02d:%02d:%02d.%03d - ", timeBuf.wHour, timeBuf.
> wMinute, timeBuf.wSecond, timeBuf.wMilliseconds);
> return string(buf);
> }
>
> void testStub(std::shared_ptr chan)
> {
> MessageProcessor::Stub client(chan);
>
> Void _void;
> AccumulateAmount amount;
> amount.set_amount(42);
>
> grpc::ClientContext ctx;
> ctx.set_deadline(IN_MILLISECONDS(100));
>
> cout << NowString() << "Making RPC\n";
> grpc::Status st = client.Accumulate(, amount, &_void);
> cout << NowString() << "Leaving testStub()\n";
> }
>
> void test()
> {
> auto chan = grpc::CreateChannel("localhost:54321", grpc::
> InsecureChannelCredentials());
>
> cout << NowString() << "  Channel Up- Testing Stub\n";
> testStub(chan);
> cout << NowString() << "  Leaving test()\n";
> }
>
>
> int main()
> {
> cout << NowString() << "Calling test()\n";
> test();
> cout << NowString() << "Exiting 'main'\n";
> return 1;
> }
>
>
>
> the output is
>
> 11:42:05.400 - Calling test()
> 11:42:05.403 -   Channel Up- Testing Stub
> 11:42:05.404 - Making RPC
> 11:42:05.506 - Leaving testStub()
> 11:42:05.507 -   Leaving test()
> 11:42:15.545 - Exiting 'main'
> Press any key to continue . . .
>
>
> It should be evident by the timestamps that the destructor for the Channel
> is taking just over 10 seconds.
>
> My question is this: *What can I do to significantly reduce the time it
> takes to destroy the grpc Channel?*
>
> My guess is that the channel is still trying to connect to the
> non-existent server/service. My guess is that the destructor for the
> channel isn't cancelling that connection request.
>
> Perhaps there's an argument/option to send to the CreateChannel call? I've
> looked at http://www.grpc.io/grpc/cpp/group__grpc__arg__keys.html, but I
> didn't see anything that looked like it would affect the initial connection
> attempt (the GRPC_ARG_INITIAL_RECONNECT_BACKOFF_MS
> 
>  seemed
> to affect the re-connection between first and second attempts)
>
>
> --
> 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/9c7f31b4-ebf0-41e1-958f-e76e661c3471%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/CAPYwnkiV%2BuhoZ6A7Pk29euNXtLpDf%3DrRehr47gt6nbH02FbCVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: gRPC c++ helloworld program compilation error

['Noah Eisen' via grpc.io]

Not sure exactly what would cause this, but I would suggest doing a clean
re-install of grpc and protobuf. Check out the steps detailed in the
comment thread of https://github.com/grpc/grpc/issues/10909. There are a
few more steps needed to install protobuf than the ones you mention.

Also, would suggest uninstalling the brew version of c ares and installing
the one in the third_party directory, just to ensure that the installed
version matches the one the code.

On Sun, May 21, 2017 at 1:36 AM, Bugsfunny  wrote:

> Please help me 
>
> On Friday, May 19, 2017 at 9:49:20 AM UTC+5:30, Bugsfunny wrote:
>>
>> Please help me with this.
>>
>> On Wednesday, May 17, 2017 at 8:16:53 AM UTC+5:30, Bugsfunny wrote:
>>>
>>> I built it from git using the following commands :
>>>
>>>  $ git clone -b $(curl -L http://grpc.io/release) 
>>> https://github.com/grpc/grpc
>>>  $ cd grpc
>>>  $ git submodule update --init
>>>  $ make
>>>  $ [sudo] make install
>>>
>>>
>>> When running "make" from the above list of commands, I got the warning "
>>> ld: warning: directory not found for option '-L//grpc
>>> /libs/opt/c-ares'" and was not able to install. Then I installed c-ares
>>> using "brew install c-ares". After which "make" worked fine.
>>> And then since protobuf was not automatically installed i executed the
>>> following commands :
>>>
>>> $ cd grpc/third_party/protobuf
>>> $ sudo make install   # 'make' should have been run by core grpc
>>>
>>>
>>> Thanks.
>>>
>>>
>>> On Wednesday, May 17, 2017 at 5:16:09 AM UTC+5:30, Nicolas Noble wrote:

 For us to be able to help a bit more with your issue, we'd need to
 understand how you built grpc and protobuf before. All signs are pointing
 at the fact you've built protobuf for 32 bits whereas the rest is building
 for 64 bits, but without more details it's hard to tell.

 On Tuesday, May 16, 2017 at 4:06:00 AM UTC-7, Bugsfunny wrote:
>
> Hi,
>
> I installed grpc 1.3.0 and protobuf 3.2.0  in OSX El Captain 10.11.6.
> I had some problems installing which gave errors saying "ld: warning:
> directory not found for option '-L//grpc/libs/opt/c-ares'"
> Then i installed c-ares from homebrew "brew install c-ares".
> Installed grpc successfully after that.
>
>
> Then I tried running "make" in the helloworld (cpp examples
> directory), but got the below errors:
>
> protoc -I ../../protos --cpp_out=. ../../protos/helloworld.proto
> g++ -std=c++11 -I/usr/local/include -pthread  -c -o helloworld.pb.o 
> helloworld.pb.cc
> protoc -I ../../protos --grpc_out=. --plugin=protoc-gen-grpc=`which 
> grpc_cpp_plugin` ../../protos/helloworld.proto
> g++ -std=c++11 -I/usr/local/include -pthread  -c -o helloworld.grpc.pb.o 
> helloworld.grpc.pb.cc
> g++ -std=c++11 -I/usr/local/include -pthread  -c -o greeter_client.o 
> greeter_client.cc
> g++ helloworld.pb.o helloworld.grpc.pb.o greeter_client.o 
> -L/usr/local/lib `pkg-config --libs grpc++ grpc` -lgrpc++_reflection 
> -lprotobuf -lpthread -ldl -o greeter_clientUndefined symbols for 
> architecture x86_64:
>   "grpc::CreateChannel(std::__cxx11::basic_string std::char_traits, std::allocator > const&, 
> std::shared_ptr const&)", referenced from:
>   _main in greeter_client.o
>   "google::protobuf::MessageFactory::InternalRegisterGeneratedFile(char 
> const*, void (*)(std::__cxx11::basic_string std::allocator > const&))", referenced from:
>   helloworld::protobuf_helloworld_2eproto::AddDescriptorsImpl()   
> in helloworld.pb.o
>   
> "google::protobuf::io::CodedOutputStream::WriteStringWithSizeToArray(std::__cxx11::basic_string  std::char_traits, std::allocator > const&, unsigned char*)", 
> referenced from:
>   google::protobuf::internal::WireFormatLite::WriteStringToArray(int, 
> std::__cxx11::basic_string std::allocator > const&, unsigned char*) in helloworld.pb.o
>   
> "google::protobuf::internal::ArenaStringPtr::AssignWithDefault(std::__cxx11::basic_string  std::char_traits, std::allocator > const*, 
> google::protobuf::internal::ArenaStringPtr)", referenced from:
>   helloworld::HelloRequest::HelloRequest(helloworld::HelloRequest 
> const&) in helloworld.pb.o
>   helloworld::HelloRequest::HelloRequest(helloworld::HelloRequest 
> const&) in helloworld.pb.o
>   helloworld::HelloRequest::MergeFrom(helloworld::HelloRequest 
> const&) in helloworld.pb.o
>   helloworld::HelloReply::HelloReply(helloworld::HelloReply const&) 
> in helloworld.pb.o
>   helloworld::HelloReply::HelloReply(helloworld::HelloReply const&) 
> in helloworld.pb.o
>   helloworld::HelloReply::MergeFrom(helloworld::HelloReply const&) in 
> helloworld.pb.o
>   
> 

Re: [grpc-io] Running tests and gdb debugging

['Noah Eisen' via grpc.io]

There are a few ways to invoke the cpp tests. The best starting place would
be to use our test running script. Try running:

tools/run_tests/run_tests.py -l cpp

That script can be toggled in many useful ways. -c will pass in different
configurations like dbg, asan, msan, tsan, and so on. And then if you
identify a particular test you want to run, the -r flag will pass in a
regex to filter which tests are run.

And of course, you can manually make and run the tests, for example:

make credentials_test
bins/opt/credentials_test

And in that case, you use an environment var to control the configuration.
For gdb use, you would do:

CONFIG=dbg make credentials_test

On Thu, Apr 20, 2017 at 5:38 AM, Kuldeep Melligeri <
kuldeepmellig...@gmail.com> wrote:

> Hi,
>
> I am new to GRPC, I am trying to figure out how to run the tests under the
> folder grpc/test/cpp/, but don't know how to trigger tests, please help me
> on this.
> I am also looking for building libraries with -g option so that it would
> be easy to debug with gdb (cpp code). Could not find the right place in
> Make file to change the flag and build.
>
> Thanks
> Kuldeep
>
> --
> 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/2218a56b-8cbc-4351-8ab4-d38761dcfd9c%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/CAPYwnki6KAN%3DWNqRM81YQQhWd7JXiO_qUVsgqSpp9i-87CFVvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: gRPC A6: Retries

['Noah Eisen' via grpc.io]

The only use case we can think of so far would be an alternative solution
to this routing affinity and hedging interaction. We initially discussed
putting the previously tried addresses in the metadata of an RPC, and then
the actual load balancing service would have access to it. But as
mentioned, this was written off because of the extra overhead.

On Wed, Mar 1, 2017 at 3:54 PM, 'Michael Rose' via grpc.io <
grpc-io@googlegroups.com> wrote:

> > To address your comments, we will be making a small change to the load
> balancing policy with respect to hedging RPCs. The change will support
> passing the local lb_policy a list of previously used addresses. The list
> will essentially be, "if possible, don't choose one of these addresses."
> For most cases this will solve your concern about the relation between
> affinity routing and hedging.
>
> It does! Thank you for your consideration, I definitely look forward to
> testing it out.
>
> > These changes will only occur in the local lb_policy. We do not want to
> send any extra data over the wire due to performance concerns.
>
> Seems reasonable to me. Out of curiosity, are there any use cases for
> doing so (other than perhaps server-aided hedge canceling)?
>
> *Michael Rose*
> Team Lead, Identity Resolution
> *Full*Contact | fullcontact.com
> 
> m: +1.720.837.1357 | t: @xorlev
> [image: Inline image 1]
>
> We’re hiring awesome people!
> See our open positions
> 
>
> On Wed, Mar 1, 2017 at 4:51 PM, Noah Eisen  wrote:
>
>> Hi Michael,
>>
>> To address your comments, we will be making a small change to the load
>> balancing policy with respect to hedging RPCs. The change will support
>> passing the local lb_policy a list of previously used addresses. The list
>> will essentially be, "if possible, don't choose one of these addresses."
>> For most cases this will solve your concern about the relation between
>> affinity routing and hedging.
>>
>> These changes will only occur in the local lb_policy. We do not want to
>> send any extra data over the wire due to performance concerns.
>>
>> gRPC support for affinity routing is ongoing, but this change to the
>> existing policy will make it easier to have hedging and affinity routing
>> work together in the future.
>>
>> On Sun, Feb 12, 2017 at 7:26 PM,  wrote:
>>
>>> > We are not supporting explicit load balancing constraints for retries.
>>> The retry attempt or hedged RPC will be re-resolved through the
>>> load-balancer, so it's up to the service owner to ensure that this has a
>>> low-likelihood of issuing the request to the same backend.
>>>
>>> That seems fairly difficult for any service with request-dependent
>>> routing semantics. Lets use a DFS as an example: many DFSes maintain N
>>> replicas of a given file block. In the case where you send a hedged request
>>> for a block, your likelihood is 1/N of requerying the same DFS node which
>>> might well have a slow disk. At least for us using HDFS, N=3 most of the
>>> time; a therefore 33% chance of requerying the same node. Even assuming a
>>> smart load balancing service which intelligently removes poorly performing
>>> storage nodes from service, it still seems desirable to ensure hedged
>>> requests go to a different node. Not having a story for more informed load
>>> balancing seems like it makes a lot of use cases more difficult than they
>>> need to be.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Sunday, February 12, 2017 at 7:24:59 PM UTC-7, Eric Gribkoff wrote:

 Hi Michael,

 Thanks for the feedback. Responses to your questions (and Josh's
 follow-up question on retry backoff times) are inline below.

 On Sat, Feb 11, 2017 at 1:57 PM, 'Michael Rose' via grpc.io <
 grp...@googlegroups.com> wrote:

> A few questions:
>
> 1) Under this design, is it possible to add a load balancing
> constraints for retried/hedged requests? Especially during hedging, I'd
> like to be able to try a different server since the original server might
> be garbage collecting or have otherwise collected a queue of requests such
> that a retry/hedge to this server will not be very useful. Or, perhaps the
> key I'm looking up lives on a specific subset of storage servers and
> therefore should be balanced to that specific subset. While that's the
> domain of a LB policy, what information will hedging/retries provide to 
> the
> LB policy?
>
>
 We are not supporting explicit load balancing constraints for retries.
 The retry attempt or hedged RPC will be re-resolved through the
 load-balancer, so it's up