[grpc-io] Re: https://github.com/grpc/grpc/issues/12539

This was not yet fixed. The github issue will track progress On Monday, September 17, 2018 at 4:07:29 PM UTC-7, Maloy wrote: > > https://github.com/grpc/grpc/issues/12539 > > Was this fixed? Should the client wait to receive the settings ack or just > start making gRPC calls... > > > > -- You r

[grpc-io] Re: Is there way I can create a secured channel from already existing socket FD.

That functionality does not currently exist in our API. What is your use case? On Tuesday, August 21, 2018 at 2:19:32 PM UTC-7, Vishal Thakur wrote: > > I have a use case where I already have a TCP connection between the client > and server and I have to use the same socket descriptors to establ

[grpc-io] gRFC G2: HFAST

I have created a gRFC for HFAST, an HTTP/2 extension for high performance, intra-cluster workloads. Please comment here or on the PR itself: https://github.com/grpc/proposal/pull/102 -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe f

[grpc-io] Re: Clarification on gRPC AsyncNext usage

Sorry for the delayed response. You should take a look at greeter_async_client2.cc , it is a good example of client code that has a dedicated thread to drive work forward on RPCs. In the main body of the

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

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 y

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

Can you specify your use case further? gRPC is an RPC library which can communicate with cloud APIs 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! > Of

[grpc-io] Re: [C++] pass custom arguments to tsi_create_ssl_*_handshaker_factory

This feature would definitely need a gRFC, see this repo . I would suggest clarifying your ideas for the design a bit further, then posting them there to get feedback from gRPC team and from security team On Tuesday, April 3, 2018 at 4:01:54 AM UTC-7, mira@

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

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 c

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

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

[grpc-io] Re: grpc::Channel thread safety

There is no need to synchronize around either of those APIs. On Tuesday, March 27, 2018 at 10:56:51 AM UTC-7, Khuzema Pithewan wrote: > > Hi, > > Thanks for doing this work. I am beginning to use c++ gRPC in Async mode > on client side. I understand completion queue access is thread safe, > howe

[grpc-io] Re: gRFC L25: Make GrpcBuffer{Reader|Writer} Public

Yes, this class would only be used with protobuf. I like your suggested rename to GrpcProtoBufferReader, and I will incorporate that change before merging. As of now, the the newly public classes are only being used by our codegen, which is already proto dependent. We will ensure that any code

[grpc-io] gRFC L25: Make GrpcBuffer{Reader|Writer} Public

Created a new gRFC, feel free to drop comments here or on the PR itself. gRFC: https://github.com/grpc/proposal/pull/61 implementation: https://github.com/grpc/grpc/pull/14541 -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this

[grpc-io] Re: does grpc c++ support pub/sub model?

gRPC support unary, server streaming, client streaming, and bidirectional streaming RPCs. Anything more elaborate will have to be built on top On Thursday, November 9, 2017 at 5:41:48 AM UTC-8, murat@gmail.com wrote: > > Hi, > > Does grpc c++ support publish/subscribe model? If it doesn't,

[grpc-io] Re: [grpc][c++] Abort at grpc::ThreadManager::MainWorkLoop when grpc_byte_buffer_destroy

Could you please provide more info about the use case? On Sunday, October 22, 2017 at 12:49:52 PM UTC-7, yihao yang wrote: > > Thread 20 (Thread 0x7fdcf5ffb700 (LWP 17797)): > #0 __lll_lock_wait_private () at > ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95 > ---Type to continue, or q

[grpc-io] Re: Size of gRPC completionqueue

For now, try running your code under debug mode, with the pending_tags enabled: export GRPC_VERBOSITY=DEBUG export GRPC_TRACE=pending_tags On Tuesday, July 11, 2017 at 4:08:45 PM UTC-7, ncte...@google.com wrote: > > The number of queued tags is not available via any public api for the > complet

[grpc-io] Re: Size of gRPC completionqueue

The number of queued tags is not available via any public api for the completion queue. I will add a github issue to add that to our internal tracing of completion queues, as I agree that it could be useful data. On Wednesday, July 5, 2017 at 9:20:04 PM UTC-7, 201...@gmail.com wrote: > > I have

[grpc-io] Re: Handling Multiple Outstanding Asynchronous Requests Responsively in Client

This seems like expected behavior to me. If is work is queued up, then some version of Next must be called in order for it to take place. On Thursday, July 6, 2017 at 12:06:00 PM UTC-7, chh...@mesosphere.io wrote: > > I did some more experiments related to this, and it seems the conclusion I > g

[grpc-io] Re: Unexpected grpc verbose messages

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

[grpc-io] Re: GRPC streaming behavior when network package loss

Can you be a bit more specific about the chain of events? Any tag/operation queued into the CQ has a guarantee that it will come out again, whether the result is a success or a timeout or a cq shutdown. On Monday, July 3, 2017 at 5:28:59 PM UTC-7, yihao yang wrote: > > Hi, > > Anyone knows is i

Re: [grpc-io] Re: connection retry policy in 1.2

The behavior you are seeing is correct, the default values being used can be found at https://github.com/grpc/grpc/blob/master/src/core/ext/filters/client_channel/subchannel.c#L62. If you would like to override the default behavior, you can use three channel args: - GRPC_ARG_MIN_RECONNECT_BACK

[grpc-io] Re: Increase socket buffer size in gRPC C++

Take a look at grpc_types.h , I think the channel arguments GRPC_ARG_MAX_RECEIVE_MESSAGE_LENGTH and GRPC_ARG_MAX_SEND_MESSAGE_LENGTH should help you out. On Tuesday, March 14, 2017 at 1:59:56 AM UTC-7, Vivek

Re: [grpc-io] Re: gRFC A3: Channel Tracing

s, so that you don't need a separate internal API > for adding nodes to each type. Or perhaps simply create some common base > class for the head_trace and tail_trace fields, and > have grpc_channel_tracer_add_trace() operate on that base class. > > Please let me know if yo

[grpc-io] gRPC A6: Retries

I've created a gRFC describing the design and implementation plan for gRPC Retries. Take a look at the gRPC on Github . -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and st

[grpc-io] Re: gRFC A3: Channel Tracing

My first link was to the blob, so it is stale. Instead use this link to the pull request itself. On Wednesday, January 25, 2017 at 10:16:46 AM UTC-8, ncte...@google.com wrote: > > I've created a gRFC describing the design and implementation plan for gRP

[grpc-io] gRFC A3: Channel Tracing

I've created a gRFC describing the design and implementation plan for gRPC Channel Tracing Take a look at the planning doc. Would love to hear some feedback on the design! -- You received this message b