[grpc-io] gRFC L118: Remove Cronet transport from gRPC C++ & Objective C

I've written a proposal to remove the Cronet transport from gRPC C++ & Objective C. https://github.com/grpc/proposal/pull/448 Feedback welcome. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving

Re: [grpc-io] Re: [gRPC-C++] grpc-c++ client seems not to index custom headers to http2 dynamic-table?

You're right that gRPC C++ doesn't compress arbitrary metadata: we get some performance advantages from being able to predictably compress important protocol metadata, and we've found that compressing arbitrary metadata interferes with this - it's usually not compressible enough, and when it is

Re: [grpc-io] Re: GRPC C++ request spent > 2s from client to server

Also worth checking how long the second RPC takes -- gRPC will lazily connect the channel by default on the first RPC, so you'll be measuring all of the connection establishment latency (for which 2 seconds is probably still too high) On Tue, Dec 19, 2023 at 11:02 AM 'veb...@google.com' via

Re: [grpc-io] Iterating over grpc_metadata_batch

I just changed grpc_core::Call::ProcessIncomingInitialMetadata on my enlistment to add the line: gpr_log(GPR_ERROR, "%s", md.DebugString().c_str()); (noting that DebugString calls Log to do its work) when I ran (the test I just happened to be debugging five minutes prior): bazel run

Re: [grpc-io] Iterating over grpc_metadata_batch

(take a look at MetdataMap<>::Log() for an API to get a textual representation out of *all* the things) On Thu, Oct 12, 2023 at 4:21 PM Craig Tiller wrote: > `PeerString` (and some others) are Non-encodable metadata: they're getting > carried around there because they make sense at the same

Re: [grpc-io] Iterating over grpc_metadata_batch

`PeerString` (and some others) are Non-encodable metadata: they're getting carried around there because they make sense at the same times as metadata, but they don't go out on the wire. So... being non-encodable Encode() skips them. There's some logging helpers that will catch them, so they show

Re: [grpc-io] how to make a grpc call using http2

Looks like you've got the http headers in place but are missing the five byte message header from grpc in your data stream On Tue, Apr 18, 2023, 6:48 AM Nikos Skalis wrote: > Hi, > > I am trying to make a gRPC call based on a HTTP2 client to work like it is > described here: >

Re: [grpc-io] C++ Async server performance of pollset_work

For our benchmarks it looks like we've hard coded requesting 5000 calls per completion queue: https://github.com/grpc/grpc/blob/master/test/cpp/qps/server_async.cc. And I think we target 3 threads per completion queue to manage contention. I'd hazard that 5000 was roughly the smallest number for

[grpc-io] gRFC L104: Ban GRPC_OP_SEND_STATUS_FROM_SERVER in combination with recv ops

I've just shared the following gRFC to eliminate a quirky corner case from the C-Core API: https://github.com/grpc/proposal/pull/336 Comments welcome. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop

[grpc-io] gRFC L101: Remove grpc_register_plugin

I've made a proposal to remove grpc_register_plugin here: https://github.com/grpc/proposal/pull/325. -- 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] gRFC L100: Narrow grpc_call_details in gRPC C Core API

This is the discussion thread for https://github.com/grpc/proposal/pull/317. grpc_call_details includes two always zero fields, let's eliminate them. -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving

[grpc-io] gRFC L99: Eliminate the GRPC_INITIAL_METADATA_CORKED from C Core

This is the discussion thread for https://github.com/grpc/proposal/pull/316, a proposal to remove an unused constant from the C core API. -- 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

Re: [grpc-io] Re: GRPC-Web In-process Proxies (client / server) c library? Possibly Non-Binary Message Encoding (JSON)

It's definitely a use case that makes sense, and I've seen a few cases here at Google where it would make sense for us too - my thought has been to create a gRPC transport in core that could understand the gRPC-Web protocol. It'd be a large amount of work, and I can't see a way that we'd be ready

[grpc-io] Proposal (L94): Elminate Slice Interning

Please see https://github.com/grpc/proposal/pull/284 - I'm proposing removing slice interning related functions from the gRPC C Core API. -- 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

Re: [grpc-io] Shared object (.so) size on Apple M1

Are you inadvertently turning on something that records debug symbols? On Wed, Aug 11, 2021 at 7:31 PM David Lopes wrote: > Hello all, > > I have a set of build scripts that spawn a docker container to build a set > of artifacts in Python using PIP. One of the dependencies of these > artifacts

Re: [grpc-io] Memory usage and grpc::ResourceQuota

ResourceQuota right now will track some but as you discovered certainly not all of the memory used by gRPC. The current behavior has been sufficient at Google to prevent some mishaps, but it's certainly not bulletproof. We'll be looking into improving this in the future. On Wed, Jul 28, 2021,

Re: [grpc-io] Streaming endpoint performance for a python client Vs golang client

What does CPU utilization look like during those 40 seconds? Are you sitting idle waiting for data, or spinning the CPU doing work? On Mon, Jun 21, 2021, 2:53 AM anand kumar wrote: > Hi, > We have a grpc server written in golang and one of the endpoints it serve > is a streaming endpoint. For

Re: [grpc-io] Re: gRPC internal thread in C++

I don't think we make any guarantees about thread count right now, over and above bounded and relatively small. We are moving to a new design around a thing called EventEngine, which will allow pluggable IO, thread pools, and timers. I expect once that work is done we'll be in a position to start

[grpc-io] Re: gRFC P5: Require a gRFC for large scale changes to Core

Trying to fix the topic name. On Thursday, April 29, 2021 at 2:01:26 PM UTC-7 Craig Tiller wrote: > Hi all, > > I've created a gRFC for ratification of large scale changes to C Core. > > Please feel free to comment. > > Craig > -- You received this message because you are subscribed to the

[grpc-io] gRFC P5: Require a gRFC for changes to Core

Hi all, I've created a gRFC for ratification of large scale changes to C Core. Please feel free to comment. Craig -- 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

Re: [grpc-io] GRFC L20: Core API to estimate the memory usage of channels and servers

Alternative (sketch) proposal: Track this via resource quota's, since we have an API that's supposed to deal with this already. I'd imagine one new API: void grpc_resource_quota_notify_on_memory_change( grpc_resource_quota* resource_quota, size_t min_memory_usage, size_t

Re: [grpc-io] GRFC L20: Core API to estimate the memory usage of channels and servers

Let's enumerate the things that need sizes in this grfc... At first cut I'd suggest: - channels - servers - calls - completion queues Do we also need slices, slice buffers? What about metadata? Server memory can change drastically over time since it also maintains a list of channels and

[grpc-io] C++ Client completion queue

For best throughput, one thread per cq, and one cq per core. -- 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

Re: [grpc-io] channel_filter.h

Something like it yes, but probably not in that exact form. On Fri, Nov 10, 2017, 2:01 PM Bruce Buffam wrote: > Is there any plan to make this header file part of the public interface of > grpc++? > Rgds, > Bruce > > -- > You received this message because you are subscribed

Re: [grpc-io] request parameters CompletionQueue and ServerCompletionQueue difference

notification_cq gets the tag back indicating a call has started. All subsequent operations (reads, writes, etc) on that call report back to call_cq. For most async servers my recommendation is to use the same cq. Places where you might not: 1. Our sync API creates a cq per call under the

Re: [grpc-io] Local in process server

There's not currently. That's not to say there can't be, but doing better would likely mean someone signs up to design and implement some kind of shared memory transport. Such an effort would likely be multi quarter to get it done right, and we've currently no plans to do so. On Tue, Aug 29,

Re: [grpc-io] Re: Default deadline per call

Prefer service configs here. Recommended deadlines will change - and if there's ever a second implementation of the interface you're exporting, it will likely have different recommended deadlines also. On Wed, May 31, 2017 at 10:58 AM 'Carl Mastrangelo' via grpc.io < grpc-io@googlegroups.com>

Re: [grpc-io] OpenSSL 1.1.0, BoringSSL, and CPython

I was under the impression that we do link BoringSSL (but don't export the symbols) with the CPython extension. On Wed, May 17, 2017 at 12:35 PM Mohamed Koubaa wrote: > Hello, > > My organization is using gRPC primarily with C++, Python, and C#, and we > have a few

Re: [grpc-io] Re: Do we have any examples to use grpc in C

Juniper has a library that might help you: https://github.com/juniper/grpc-c On Tue, Apr 11, 2017 at 10:02 AM wrote: > Hello, > > I was wondering if there is an update on this subject. Is it possible to > use gRPC with C? Thank you. > > Regards, > Kostas > > > On Tuesday,

Re: [grpc-io] Proposal: true binary encoding for metadata

gt; jh...@bluegosling.com >> >> On Wed, Mar 29, 2017 at 1:28 PM, 'Eric Anderson' via grpc.io < >> grpc-io@googlegroups.com> wrote: >> >>> On Wed, Mar 29, 2017 at 10:10 AM, 'Craig Tiller' via grpc.io < >>> grpc-io@googlegroups.com> wrote: >>>

Re: [grpc-io] Re: GRPC Server Threading

gt;>>> >>>>> When you say "*The C++ server has two threading models available: >>>>> sync and async. Most users will want to use the sync model: the server >>>>> will >>>>> have an (internal) threadpool that manages multiplex

Re: [grpc-io] Re: Proposal to allow C++ to be used in gRPC Core

There's no apriori reason why this should increase binary size: C code compiled as C++ should end up approximately the same size, and we're not introducing new dependencies. It's probably worth introducing something like a Bloaty McBloatface diff much as we do a benchmark diff, but I'd hold

Re: [grpc-io] Re: Understanding the build process of project

Thanks for the feedback. I wish you all the best in finding another project to contribute to. On Mon, Apr 3, 2017, 5:43 AM Mike Lee wrote: > thanks for that chris. > > It's a shame really, unfortunately I'm just unable to > contribute/participate in a project whose

Re: [grpc-io] Re: Proposal to allow C++ to be used in gRPC Core

Reread the proposal: one of the key requirements here is no libc++ dependency. We'll be using the C++ language, but in a way that avoids all the runtime baggage. I expect some work for wrapped language folks here, and the implementation plan is careful to ensure we can roll back quickly if this

[grpc-io] Re: Proposal to allow C++ to be used in gRPC Core

https://github.com/grpc/grpc/pull/10426 and https://github.com/grpc/grpc/pull/10427 start to show what this might look like. On Sat, Apr 1, 2017 at 7:33 AM Craig Tiller wrote: > I've created a proposal to allow C++ to be used in gRPC Core here: >

Re: [grpc-io] URGENT: Crash in grpc code while running asynchorous stream for long time.

If gRPC allowed you to start a new write before the old one completed, then there's an opportunity for unbounded memory growth, which could crash your application (out of memory errors). Instead, we limit the outstanding write requests to one, and force the application to deal with push-back. In

Re: [grpc-io] URGENT: Crash in grpc code while running asynchorous stream for long time.

It looks like you're trying to start a new write while there's one already outstanding. This is unsupported and will crash (although we should admittedly give better messaging). You need to ensure that the previous write has delivered it's tag back via the completion queue before starting a new

[grpc-io] Re: gRPC C++ async api doc and sample code

The writeup looks great: it'd be good to get this as a .md file in our doc/c++ tree (would love to see a pull request). I know there were some folks looking to update the example code also... I'm going to have them jump on this thread for where to go with the code. On Thursday, March 2, 2017

Re: [grpc-io] can I get the raw protobuf serialization additionally?

Look to the generic APIs: they're async and perform no serialization. On Sat, Mar 18, 2017, 8:29 AM Mario Emmenlauer wrote: > > I'd like to implement client-side caching in a C++ client, by storing > the request and reply in a map, and answering subsequent requests from >

Re: [grpc-io] Re: gRPC Server Core Affinity

We don't have API's in place for the synchronous API, but for the async API this is fairly easy (and indeed much of the point of that API) - you get to call CompletionQueue::Next, and the thread that's calling that function can be bound to a core. On Fri, Mar 3, 2017 at 7:40 AM

Re: [grpc-io] gRFC L1: C++ streaming coalescing API's

gt; On Fri, Jan 13, 2017, 5:29 PM Louis Ryan <lr...@google.com> wrote: > > How is this logically different from per-stream 'corking' ? We want the > ability to coalesce the writes for groups of messages on a stream, not just > the head and tail of a stream, it seems like a generi

Re: [grpc-io] Re: gRFC for C-core endpoint extension API

I'd lean towards not doing this if it requires making public API's of that much of gRPC's internals. On Fri, Feb 17, 2017 at 10:20 AM 'Michael Lumish' via grpc.io < grpc-io@googlegroups.com> wrote: > It has been pointed out to me that most endpoints that would be supported > by this change would

Re: [grpc-io] Adding external sockets to grpc event loop

There's not currently, but there's no deep philosophical reason not to. A design is needed for how it would function. On Thu, Feb 16, 2017, 9:22 PM Aditya wrote: > Is there a way to add external tcp socket fds to grpc event loop? > > -Aditya > > -- > You received this

Re: [grpc-io] async model rpc sequence

You've misunderstood :) The server application needs to request incoming calls, and we need to match them to requests as they come in. We arbitrarily reverse to order of matching (because we get a faster implementation), but preserve the order of actual requests presented to the application. On

Re: [grpc-io] Re: gRFC A4: Header Extraction

Alternative proposal: - this mechanism only allows single field extraction, with no string processing - when we do the affinity based load balancing design, we allow some level of string manipulation there Advantages: - this feature becomes universal (if we need to provide a smaller binary, we

Re: [grpc-io] Re: gRFC A4: Header Extraction

Alfred linked me to some docs explaining. FTR this seems like very use-case specific bloat being piled onto gRPC, with a clearly stated aim to pile more bloat onto the mechanism in the future. My recommendation would be to drop the delimiter and find some other solution for these use-cases. On

Re: [grpc-io] Re: gRFC A4: Header Extraction

Can you describe your actual use case for this, and why it can't be accomplished server side? (that seems to be completely missing here, or I've missed it somewhere). Also, what is CEL? On Thu, Feb 2, 2017 at 2:46 PM Alfred Fuller wrote: > Why not make the headerName a key

Re: [grpc-io] Re: gRFC A4: Header Extraction

Any proposal that adds a dependency to a regex library is an absolute non-starter in my mind. I'd really encourage solutions that can take the proto data at face value: if client side demuxing needs a more precise view of some data, then perhaps a better solution is to change the proto. On Thu,

Re: [grpc-io] Re: gRFC A4: Header Extraction

I'm very wary about the delimiter character: it seems like it opens the door to adding a whole host of renormalization filters to this spec, and such will eventually lead to mutually inconsistent implementations. I'd strongly prefer that we drop any massaging of the fields client side and instead

Re: [grpc-io] gRFC L1: C++ streaming coalescing API's

gically different from per-stream 'corking' ? We want the > ability to coalesce the writes for groups of messages on a stream, not just > the head and tail of a stream, it seems like a generic cork mechanism can > cover headers and trailers too > > On Fri, Jan 13, 2017 at 5:19 PM, 'Crai

Re: [grpc-io] best way to force shutdown of synchronous C++ server

There's not. We've talked about having a std::function argument to Shutdown that would fire when the deadline elapses (I'm against a particular concurrency expression (mutex/condvar for instance) here since every app ends up wanting different things). There's no plans to implement it just yet,

Re: [grpc-io] gRFC A2: Service Configs in DNS

How does the percentage field work? Do clients roll a die to determine if they're in the canary subset? Or is there a deterministic way of determining this? On Thu, Jan 19, 2017 at 8:57 AM 'Mark D. Roth' via grpc.io < grpc-io@googlegroups.com> wrote: > I've created a gRFC describing how service

Re: [grpc-io] Re: QUIC support in gRPC

Do note that Cronet provides the client side, but you'll also need something to terminate QUIC and convert to HTTP2 to talk to any of the mainline gRPC servers. On Wed, Jan 18, 2017 at 8:07 AM Gustavo García wrote: > Perfect. Thank you very much Kailash and Penn. > > El

Re: [grpc-io] gRFC L1: C++ streaming coalescing API's

k mechanism can > cover headers and trailers too > > On Fri, Jan 13, 2017 at 5:19 PM, 'Craig Tiller' via grpc.io < > grpc-io@googlegroups.com> wrote: > > I've opened a gRFC allowing for coalescing of writes for streaming RPC's > from our C++ API here: https://github.com/grpc/prop

Re: [grpc-io] [C++/async/stream] getting "pure virtual method called" in grpc_completion_queue_next ()

You probably want to first do 'handle SIG36 noprint' to let gdb pass the (totally legitimate) signal to the application. On Tue, Nov 15, 2016 at 8:56 AM wrote: > > Hi all, > > I've created a tiny code sample that is based off the hello world async > greeter example. I keep

Re: [grpc-io] about client source IP address

Which language are you working with? On Mon, Nov 14, 2016 at 4:52 PM wrote: > > How to get the client source IP address from the gRPC server > > -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this

Re: [grpc-io] gRPC endpoint with non-root path

It's not possible, and not something we're currently planning. On Fri, Nov 4, 2016 at 5:18 AM Mark NS wrote: > Maybe (hopefully) I'm missing something very simple, but I can't seem to > figure this out. > > > I have a set of Python gRPC services that I would like to

Re: [grpc-io] Concurrency in synchronous c++ service

Server methods can absolutely be called from many threads. On Thu, Oct 27, 2016 at 7:28 AM wrote: > Hi, > > In the synchronous case (example: > http://www.grpc.io/docs/tutorials/basic/c.html), are the functions > executed concurrently, or sequentially? > For instance in

Re: [grpc-io] gRPC compilation for XP (v140_xp)

That sounds like a good summary of the complications with XP. We have no plans to support the platform, especially since it's well past end of life. On Wed, Oct 19, 2016 at 8:39 AM Amit Waisel wrote: > I am trying to compile the C++ code for XP platform. I know it is not >

Re: [grpc-io] Re: InProcess for C#

I expect we'll be putting this together early Q1 2017. On Thu, Oct 13, 2016 at 11:14 AM 'Jan Tattermusch' via grpc.io < grpc-io@googlegroups.com> wrote: > On Fri, Oct 7, 2016 at 4:05 PM, Malc wrote: > > I have a slightly different usecase in mind. > We would like to move a

Re: [grpc-io] Custom Endpoint

With the Makefile it should be fairly trivial to just build the unsecure libs. On Fri, Oct 7, 2016 at 7:24 AM Robert Bielik wrote: > Yes, I got into trouble fairly quickly. First off is the requirement for > Go. I'm only planning using unsecure transport, is it possible

Re: [grpc-io] Custom Endpoint

Note that CMake is experimental and community supported at this point in time. On Fri, Oct 7, 2016 at 7:09 AM Robert Bielik wrote: > Now that I see that there is added CMake support in v1.0.0, I'm heading > there straight away!! :D > > > Den fredag 7 oktober 2016 kl.

Re: [grpc-io] Custom Endpoint

How long until you can move to 1.0? Either way you should be able to squelch this error by setting the channel arg GRPC_ARG_ALLOW_REUSEPORT to 0. On Fri, Oct 7, 2016, 2:05 AM Robert Bielik wrote: > Hi Nicolas, > > I ran our server with grpc log out, and there is an

Re: [grpc-io] Compile gRPC in VS 2005

No, and it will never be. VS2015 is a free download. I'd encourage you to upgrade. On Thu, Sep 29, 2016, 2:48 AM Eugene Abramov wrote: > Hello, > > Is it possible to compile grps c/c++ in VS 2005? > > Thanks > > -- > You received this message because you are subscribed to

Re: [grpc-io] Re: gRPC with TCP transport?

Start with the question: "What would I change in HTTP/2 to improve QPS?" When we asked that question, we didn't really come up with anything interesting, and so we went with HTTP/2. (To be fair, there are some things we'd probably love to change in HTTP/2, but they're not about raw QPS... I'd

Re: [grpc-io] Re: how does grpc handle DNS address changes?

(I'm assuming Node or C++ based on previous conversations with Yaz/Abhishek) On Thu, Aug 18, 2016 at 5:06 PM wrote: > What language is your client written in? > Java, C++ or Go? > > For GO, there are two ways to get list of IP addresses for a FQDN Name. > > IIRC, one of the

Re: [grpc-io] Re: how does grpc handle DNS address changes?

The behavior is supposed to be that we periodically (with exponential back-off) retry resolution and then connection until we get a successful connection. We currently rely on getaddrinfo to do the resolution, so we don't get any insight into the TTL on the dns entry - that's something we'll pick