Re: [grpc-io] Re: gRPC Android stub creation best practice? DEADLINE_EXCEEDED but no request made to server

nges in the device's internet state, so it should be irrelevant to detecting (or failing to detect) server-side disconnections, but it's a relatively new feature and would be worth ruling it out as a source of the problem. Thanks, Eric > > On Wednesday, January 16, 2019 at 7:30:42 PM

Re: [grpc-io] Re: relaying grpc calls

es; it removes the client from having to know what goes where. On Tue, Jan 15, 2019 at 11:51 PM wrote: > @Eric, I did not find any mention of relay_request in the documentation. > However, I *loved* the service-agnostic proxy. > While reading the code it dawned on me that I can run an

Re: [grpc-io] Re: gRPC Android stub creation best practice? DEADLINE_EXCEEDED but no request made to server

roblem for you... that's unexpected for a DEADLINE_EXCEEDED problem. But in any case, you probably want to set idleTimeout() and keepaliveTime() on the builder. On Jan 17, 2019, at 5:51 PM, 'Eric Gribkoff' via grpc.io < > grpc-io@googlegroups.com> wrote: > > > > On Thu, Jan 1

Re: [grpc-io] Re: HelpNeeded: in RoundRobinLoadBalancerFactory usage properly

You're probably using ELB in L4 LB mode (as a TCP proxy). The three addresses you see are probably the ELB's own addresses. ELB itself would see the greater number of backends. You can verify that you are understanding the code using a tool like "dig" to issue DNS requests. It shows you all the ad

Re: [grpc-io] Re: Python Rendezvous exception when running python server, python client and C++ client on the same PC

r, do you still see this intermittent exception in the Python client? Eric On Wed, Feb 20, 2019 at 6:57 AM Alex wrote: > I should add that the Python client application which owns the Python grpc > client is the one that runs the C++ grpc client as a subprocess in case > that makes a

Re: [grpc-io] Re: Python Rendezvous exception when running python server, python client and C++ client on the same PC

at only uses gRPC, without the websockets, to be able to help debug this further. Thanks, Eric On Mon, Mar 4, 2019 at 2:36 AM Alex wrote: > Hi Eric, > > Just wondering if you had time to run my attached example and managed to > reproduce the problem? > > Thanks, > Alex. &g

Re: [grpc-io] Load balancing policy question.

> > Is it possible to create a per-connection load balancing? In other words > create a stub on the client side, so that dns resolution will be performed > only on stub creation and all rpc calls on that stub will be invoked on the > same grpc server? > In general, no, there isn't one that does th

Re: [grpc-io] Load balancing policy question.

> What I meant by subsequently created channel is: does every call for > CreateChannel/CreateCustomChannel perform an explicit DNS lookup, or > subsequent call may reuse a cached result of successful resolution from > the previous one? > Each channel does its own DNS lookup. Granted, the DNS loo

Re: [grpc-io] Help with Compression on grpc

> > 1. On the wire, it'll be compressed to 5MB payload and on the serve side > when I open up the gRpc request, Payload will be of 70MB size ? > Yes. 5 MB on-the-wire. The gRPC server will decompress the payload automatically for the server. 2. On the Server side, I do not have to explicitly ment

Re: [grpc-io] Re: Following exception is coming when invoking gRPC method as REST endpoint through enoy

We need more information. I asked some questions on the same question at https://github.com/grpc/grpc-java/issues/5603. On Tue, Apr 16, 2019 at 5:07 AM shifeifei via grpc.io < grpc-io@googlegroups.com> wrote: > > > 在 2018年5月30日星期三 UTC+8下午8:08:15，Mahesh Kanote写道： >> >> Hi, >> >> Following exceptio

Re: [grpc-io] Small example of transfer the file

https://stackoverflow.com/a/46106469/4690866 may be helpful. It links to another question that has multiple answers that may each provide some help. On Fri, Apr 19, 2019 at 5:25 AM wrote: > Hi everyone! Please show me a small example transfer the file from the > client to the server on C#. > I t

[grpc-io] gRFC L51: Java proposal to remove Protobuf Nano support

This is the discussion for https://github.com/grpc/proposal/pull/141 Please provide comments and concerns. -- 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+un

[grpc-io] Re: bidirectional - calling rpc method each time when message arrived?

ing-grpc-for-long-lived-and-streaming-rpcs-eric-anderson-google> (slides are near "PDF" and video is "link to session recording"), longer-lived bidi streams are harder to use and open you to different problems. Long-lived RPCs in particular can require special care. So make

Re: [grpc-io] is it possible to use several TCP ports for one gRPC connection?

No, that's not easy. gRPC expects a single socket for reading and writing. On Thu, May 2, 2019 at 12:07 PM Antonio Goncalves wrote: > Hi Everyobody, > > how are you doing? > > I'm not so familiar with the high levels of gRPC, as I work in a more HW > level. I'm trying to integrate the gRPC Stack

Re: [grpc-io] Triying to undestand Throttling Retry Attempts (gRPC retry Design Proposal)

On Fri, May 3, 2019 at 9:39 AM wrote: > How token_count will rises over the threshold if "RPCs will not be > retried" ? > token_count is modified for the initial attempt as well, not only after a failed retry. So as other RPCs succeed on their first attempt tokens will be refilled. Is it rising

Re: [grpc-io] Re: Grpc Java Server Side Streaming server stream cancellation detection

When the TCP connection is detected to be broken, all RPCs on that connection are cancelled. This calls context.cancel() . That immediately does two things: changes the boolean that isCance

Re: [grpc-io] Re: Grpc Java Server Side Streaming server stream cancellation detection

Yes. Java does I/O on a separate thread, and that thread notices the broken TCP connection. On Mon, May 6, 2019 at 8:13 AM Isuru Samaraweera wrote: > So it seems breaking of TCP connection is detected by a separate thread > than the main thread right? > > > On Mon, May 6, 2019

Re: [grpc-io] Re: grpc-java build failure

Most users have no need to compile/build grpc-java directly. The document linked to earlier states at the beginning: "Building is only necessary if you are making changes to gRPC-Java or testing/using a non-released version (e.g. master HEAD) of gRPC-Java library." We have pre-built binaries for t

Re: [grpc-io] Re: grpc-java build failure

On Tue, May 21, 2019 at 11:42 AM Eric Anderson wrote: > If you want/need to build grpc itself, the COMPILING.md > <https://github.com/grpc/grpc-java/blob/master/COMPILING.md> referenced > earlier does describe how. Look for mentions of MinGW and Visual C++, > depending on whi

[grpc-io] gRPC Java 1.21.0 Released

gRPC Java 1.21.0 is released and available on Maven Central. Much of it is available on JCenter, but some artifacts are still missing . https://github.com/grpc/grpc-java/releases/tag/v1.21.0 Dependencies - context: Removed unnecessary deps from B

Re: [grpc-io] Switch Network interfaces while stream is running

Streams are bound to the underlying TCP connection they were "placed on." So the questions are answered by "what happens with TCP in that scenario." On Fri, Jun 14, 2019 at 12:15 AM tobix24 via grpc.io < grpc-io@googlegroups.com> wrote: > Hi group, > > are there any experiences here how GRPC hand

Re: [grpc-io] Detect TLS mismatch between Client and Server

Correct. If the client expects TLS you will get an error if connecting to a plaintext server. Some languages may provide more error information than others, but in all language that information is intended for developers, not programs to inspect. On Thu, Jun 13, 2019 at 12:00 PM Dave Quigley wrot

Re: [grpc-io] What does te trailer headers means in gRPC's HTTP2 headers

See https://tools.ietf.org/html/rfc7230#section-4.3 Proxy would mainly be an L7 reverse proxy, like, say Nginx. When HTTP reverse proxies don't support trailers, they are supposed to remove "TE: trailers" from the request. If "TE: trailers" makes it from the client to the server it provides strong

[grpc-io] gRPC Java v1.21.1 Released

gRPC Java 1.22.1 is released and available on Maven Central and JCenter. https://github.com/grpc/grpc-java/releases/tag/v1.21.1 This release resolves the DoS vulnerability CVE-2019-9515 (SETTINGS flood). Users using the grpc-netty server with untrusted clients should upgrade. Bug fixes - nett

[grpc-io] gRPC Java v1.22.2 Released

gRPC Java 1.22.2 is released and available on Maven Central and JCenter. https://github.com/grpc/grpc-java/releases/tag/v1.22.2 This release resolves the DoS vulnerability CVE-2019-9515 (SETTINGS flood). Users using the grpc-netty server with untrusted clients should upgrade. Bug fixes - nett

Re: [grpc-io] Default netty buffer size in java

Can you explain why you are interested or what you are doing? From the perspective of users, unary gRPC requests are simultaneously unbuffered and fully buffered, depending on what the user is truly asking. NettyWritableBufferAllocator isn't related to network buffers. It produces buffers for seri

Re: [grpc-io] Default netty buffer size in java

On Thu, Aug 15, 2019 at 11:55 AM Rama Rao wrote: > We are proxying the requests with 2mb via a proxy and seeing that proxy is > seeing partial request so interested in understanding the behaviour bit > more. > Hmmm... Depending on what you are seeing there can be a lot of explanations. 1. HTTP/

Re: [grpc-io] Default netty buffer size in java

at 5:54 PM Rama Rao wrote: > Thanks for the detailed explanation. This case is reverse proxy so gRPC > client is initiating the connection so probably setting the window might > change the behaviour looks like? Thanks again for the explanation > > On Thu, 15 Aug 2019 at 2:07 PM, Eric A

Re: [grpc-io] Build Process When Using Multitude Languages

You may be interested in https://github.com/googleapis/gapic-generator/tree/master/rules_gapic . Granted, that is only really intended for googleapi's usage, but it is solving the same basic problem. Biggest issue is probably that it does a lot more than you are wanting. It creates a native package

Re: [grpc-io] Re: How can I close all connections in a java ManagedChannel and restart them?

It seems you are thinking of the OS-based TCP_USER_TIMEOUT. But there is also keepalive that you can configure, which is what A8-client-side-keepalive.md is talking about.

Re: [grpc-io] recovering from server sending too large a message in grpc-java

On Thu, Sep 19, 2019 at 1:18 PM Steven Parkes wrote: > This is related to https://github.com/grpc/grpc-java/issues/2563. The > tl;dr of https://github.com/grpc/grpc-java/issues/2563 is "don't do that" > which we agree with in principle but don't have an efficient way to > implement. > There's th

[grpc-io] Re: How grpc-health-probe (gRPC health checking on Kubernetes) differentiates between liveness and readiness probes

The health probe *doesn't* distinguish between the two. It is a binary that is run, and if you use the same arguments you will get the same results. The binary only accesses the Health service (/grpc.health.v1.Health/Check as mentioned in its README). One option is you can pass the `-service` c

Re: [grpc-io] java tutorial outdated?

On Mon, Oct 28, 2019 at 1:15 PM vazor wrote: > The README link there points to gRPC instead of protobuf, not sure if that > is intentional. And for better clarity perhaps add "a special gRPC Java > plugin which is downloaded separately" and "the protoc build plugin can > automatically download th

[grpc-io] gRPC@CloudNativeCon NA 2019

dinate! You may also be interested in these talks: - Monday 11:55am. Intro to gRPC <https://kccncna19.sched.com/event/Uahn/intro-to-grpc-jayant-kolhe-eric-anderson-google> by Jayant Kolhe - Monday 3:20pm. Design Decisions for Communication Systems <https://kccncna

[grpc-io] Re: gRPC@CloudNativeCon NA 2019

rx> by Luis Pabón On Mon, Nov 18, 2019 at 11:01 AM Eric Anderson wrote: > CloudNativeCon NA 2019 is upon us! I know it would have been better to > send this earlier, but better late than never. > > Several of us from Google's gRPC team will be at the event, and we'

Re: [grpc-io] How to send an application specific error code to clients in grpc-java

You can provide additional details in the Metadata, which can be attached to a StatusException/StatusRuntimeException. You would define a proto message to hold the specific details you care about and then pass it in the Metadata directly on in a google.rpc.Status. See https://stackoverflow.com/a/48

Re: [grpc-io] How to send an application specific error code to clients in grpc-java

eakage. On Wed, Dec 11, 2019 at 5:38 PM Hiroyuki Yamada wrote: > Hi Eric, > > Thank you very much for the quick response. > Yes, I thought so, but asRuntimeException(metadata) is an experimental API > so I was wondering if there is another better way. > (Seems like StatusProto is

[grpc-io] gRPC-Java v1.26.0 Released

gRPC Java 1.26.0 is released and should be available on Maven Central and JCenter. https://github.com/grpc/grpc-java/releases/tag/v1.26.0 Dependencies - Bump protobuf-java to 3.11.0. - Bump protobuf-javalite to 3.11.0. This brings lite in-line with full protobuf. Be aware that the Maven

[grpc-io] Re: gRPC-Java v1.26.0 Released

github.com/liusheng>) - Nayana Thorat (@Nayana-ibm <https://github.com/Nayana-ibm>) - Steve Rao (@steverao <https://github.com/steverao>) - Tomo Suzuki (@suztomo <https://github.com/suztomo>) - Yongwoo Noh (@yonguno <https://github.com/yonguno>) On Wed, Dec 18,

Re: [grpc-io] configure connect timeout for grpc java client?

usage would be stub.withDeadlineAfter().rpcMethod(). Thanks, Eric On Fri, Dec 20, 2019 at 2:24 AM 'Christoph John' via grpc.io < grpc-io@googlegroups.com> wrote: > Hmm, never wanted to do that. But I guess you'll have to shutdown() the > channel. > > Chris. >

Re: [grpc-io] configure connect timeout for grpc java client?

ar RPC - monitor the connection state of your channel via https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#getState-boolean- and https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#notifyWhenStateChanged-io.grpc.ConnectivityState-java.lang.Runnable- . - Eric On

Re: [grpc-io] what's the difference between enableRetry and waitForReady?

A major difference is that, if retries are enabled, the server can reply with an error code that's been configured as retryable and the client can retry the RPC. On Thu, Dec 26, 2019 at 2:07 AM Elhanan Maayan wrote: > > from my POV those seem to be identical except for the fact that > waitForRea

Re: [grpc-io] what's the difference between enableRetry and waitForReady?

veral retriable error code, can my application > receive any call back about it? > > On Thu, Dec 26, 2019 at 10:54 PM Eric Gribkoff > wrote: > >> A major difference is that, if retries are enabled, the server can reply >> with an error code that's been config

[grpc-io] grpc-java contributors: Android projects integrated into main build

I'm about to merge https://github.com/grpc/grpc-java/pull/6132. This will add the Android projects to our main project, so they will build by default now. If you have an Android SDK, I'd encourage you to build/test the Android projects as part of the normal development process. However, if you don

[grpc-io] gRPC-Java v1.27.0 Released

gRPC Java 1.27.0 is released and should be available on Maven Central and JCenter. The binaries were published January 29th. I was slow producing the release notes... https://github.com/grpc/grpc-java/releases/tag/v1.27.0 *Bazel users should migrate to maven_install. Please open an issue to repor

Re: [grpc-io] Handling nested contexts on the server side

If you want to store temporary state just as long as a client is around, you can use a stream. For example, transactions and locks and use a gRPC streaming call to good success, because if the client crashes the stream will (eventually) fail. Although it is a bit hard to tell in your case how long

Re: [grpc-io] [Java] Flow control window setting on Okhttp client stalls stream

Hmm... it looks like this was missed in our triage. I'm looking into why. I'm glad you filed https://github.com/grpc/grpc-java/issues/6685 for the okhttp bug. Ideally you would use Netty, but it is strange that Netty is slower than OkHttp. My best guess (based on zero evidence) is something is goi

Re: [grpc-io] Huge increase of precompiled native libraries for Android and iOS

+Jan Tattermusch , who (I think) knows more about our Unity builds On Wed, Feb 19, 2020 at 10:13 AM 'Jihun Cho' via grpc.io < grpc-io@googlegroups.com> wrote: > we have completely different codebase for ios and android. so, it happened > on both sides sounds interesting. > i can't speak for the

Re: [grpc-io] Android DownloadManager with gRPC

using something like a HTTP server + a specific file download library/client. I would recommend just running a separate HTTP server for your file download needs. Thanks, Eric On Thu, Mar 26, 2020 at 4:29 AM clement jean wrote: > Hi, > > > > I recently posted a question on StackOve

Re: [grpc-io] Is it possible to use an existing Applicaiton server to serve gRPC endpoints?

The Netty-based server is currently the only server offered by grpc-java. There is a PR to allow exposing gRPC services through the servlet 4 API. However, due to how grpc methods are managed, the servlet would need to be deployed with the `/` path. Th

Re: [grpc-io] gRFC discussion: PR vs mailing list

On Fri, Apr 10, 2020 at 3:32 PM 'Christopher Warrington (CHRISTOPHER)' via grpc.io wrote: > I've noticed that much of the valuable discussion in gRFCs [1] these days > is > happening via GitHub's PR interface. > Oh, yeah... This has probably always been happening, though. I have seen some detail

Re: [grpc-io] Are calls to StreamObserver serialized?

On Wed, Apr 29, 2020 at 3:21 PM wrote: > Interesting - thank you very much! I did see this in the StreamObserver > doc > > : > > "Since individual StreamObservers are not thread-safe, if multiple > threads will be writing

Re: [grpc-io] Re: Grpc excessive default memory usage

Thanks for the additional information. On Wed, May 13, 2020 at 11:41 PM wrote: > Thanks Eric for the reply. > > Couple of things. I am not able to get this when you say that gRPC java is > not optimized for this type of large file. My individual message size is > 1024 bytes on

Re: [grpc-io] Re: Using the binder as the transport for gRPC

It's not good form to revive 3 year old threads. It is better to start a new thread and just reference back to the old thread saying you noticed it. No binder transport came out of this discussion, to my knowledge. However, I'm aware of a gRFC in the works (not yet posted) for a Binder transport.

Re: [grpc-io] GRPC endpoint server

What language are you interested in? There is the "standard" grpc-java implementation . Or are you looking for more? On Mon, Jun 15, 2020 at 11:19 AM wrote: > Hi > > I'm looking for gRPC based implementation server/endpoint which van be > deployed in kubernetes

Re: [grpc-io] C# gRPG EF6 concurrency (rowversion)

What you're dealing with is very similar to etags. The Google Cloud API design patterns suggests "an API should include a string field etag in the resource definition." Looking at a few

Re: [grpc-io] Re: Server-side full-stream decompression

I responded on https://github.com/grpc/grpc-java/issues/7164 . In short, full-stream decompression is not fully implemented and should not be used. On Thu, Jun 25, 2020 at 6:04 AM wrote: > Sorry wrong flag posted. C++ actual flag in client is > "GRPC_COMPRESS_STREAM_GZIP". > > Thanks, > Parth >

Re: [grpc-io] Re: Using the binder as the transport for gRPC

:33 PM Eric Anderson wrote: > It's not good form to revive 3 year old threads. It is better to start a > new thread and just reference back to the old thread saying you noticed it. > > No binder transport came out of this discussion, to my knowledge. However, > I'm aware of

[grpc-io] gRFC L74: Java Channel Credentials

This is a thread to discuss https://github.com/grpc/proposal/pull/198 It is an enhancement for Java to add ChannelCredentials and ServerCredentials. This brings Java closer to C and Go (but stronger to C than Go with the composite creds). We've been avoiding this for years as it is quite a bit of

Re: [grpc-io] Simple Client Interceptor

On Thu, Jul 16, 2020 at 9:32 AM Sivabalan wrote: > This is not a breaking change, my proposal is to introduce a simpler > abstract class which devs can choose to extend rather than implementing > ClientInterceptor. > ClientInterceptors are really just a small tweak to a Channel to allow them to

Re: [grpc-io] Simple Client Interceptor

On Mon, Jul 20, 2020 at 8:54 AM Sivabalan wrote: > On Mon, Jul 20, 2020 at 11:02 AM Eric Anderson wrote: > >> This mainly supports "observing" client interceptors, that don't need to >> make any changes to the RPC other than Metadata. That helps many, but lots &

Re: [grpc-io] Updating host to be routed to by an interceptor

Interceptors are not great for routing to different backends. That'd be the job of a LoadBalancer. For your case, it sounds like you could also just create a Channel implementation instead of a ClientInterceptor. It could create multiple ManagedChannels and decide which to use based on the applicat

Re: [grpc-io] how-to make a gRPC call using a HTTP/2 client

Here is the most basic gRPC call using curl: $ echo -ne '\000\000\000\000\000' | curl --http2-prior-knowledge http://localhost:50051/helloworld.Greeter/SayHello -H content-type:application/grpc --data-binary @- | od -t x1 000 00 00 00 00 08 0a 06 48 65 6c 6c 6f 20 015 That sends an uncomp

Re: [grpc-io] how-to make a gRPC call using a HTTP/2 client

without the leading slash. But in HTTP it has the leading slash since it is a path. On Tue, Jul 21, 2020 at 8:15 AM Eric Anderson wrote: > Here is the most basic gRPC call using curl: > > $ echo -ne '\000\000\000\000\000' | curl --http2-prior-knowledge > http://localhost:500

Re: [grpc-io] Re: Tracking stats for a single clientCall and across diff client calls within an interceptor

Depending on what you are tracking, you may still have to consider thread-safety between sending and receiving; the ClientCall and Listener are *independently* non-thread-safe and so may need synchronization if reading stats from both. Note that Listener.onClose is the "end of the RPC" but the send

Re: [grpc-io] Under high load, clients get StatusRuntimeException: UNKNOWN: channel closed

locking operation in the Netty event loop? I don't think MAX_CONCURRENT_STREAMS-related capacity issue would result in this stack trace, as the connection should be more or less cleanly rejected rather than moving a connected channel to inactive mid-handshake as suggested by the provided stacktr

[grpc-io] gRPC-Java 1.31.0 Released

gRPC Java 1.31.0 is released and available on Maven Central. The release should be available on JCenter shortly. *gRPC Java 1.31.0 Release Notes* API Changes - api: ManagedChannelBuilder.nameResolverFactory is now marked deprecated. It has long been our plan to remove the function, but was

Re: [grpc-io] Under high load, clients get StatusRuntimeException: UNKNOWN: channel closed

CPU from running other threads as well. Thanks, Eric On Thu, Jul 30, 2020 at 1:34 PM Ethan Cheng wrote: > Hi Eric, thanks for looking into this. > I agree that this has nothing to do with `MAX_CONCURRENT_STREAM` and I can > see why you are thinking about the blockings in the Netty

Re: [grpc-io] Re: NettyServerBuilder difference between executor() and workerEventLoopGroup()

Please do not comment on three-year-old threads. Instead, start a new email thread and just refer back to the original. The event loops are behind-the-scenes. You only need to mess with them if you want to change their sizes (how many threads are used) or their types or are using directExecutor().

[grpc-io] Re: gRFC L74: Java Channel Credentials

mment-670162341> On Fri, Jul 17, 2020 at 3:44 PM Eric Anderson wrote: > This is a thread to discuss https://github.com/grpc/proposal/pull/198 > > It is an enhancement for Java to add ChannelCredentials and > ServerCredentials. This brings Java closer to C and Go (but stronger to C >

Re: [grpc-io] Building a grpc reverse proxy using client headers

Using a gRPC-based proxy to provide your own logic sounds good and fine. Since you just need headers you could make your own HTTP/2 proxy, but there's nothing wrong with using gRPC as the proxy in my mind. On Thu, Aug 6, 2020 at 1:47 PM wrote: > I couldn't find a lot of documentation on how the

[grpc-io] gRPC Java 1.31.1 Released

gRPC Java 1.31.1 is released and available on Maven Central. Bug Fixes: - netty: The environment variable GRPC_EXPERIMENTAL_AUTOFLOWCONTROL=false will now disable the BDP monitoring introduced in v1.30.0. This is intended to help diagnose a “too_many_pings” compatibility issue and will b

Re: [grpc-io] Detecting client disconnections from server streaming (grpc-java)

On Wed, Aug 19, 2020 at 10:38 AM Greg Ludington wrote: > In server-side streaming, how does an ungraceful disconnection by a client > get communicated back to the server? It'll be a cancellation. "All bad things" become cancellation on server-side. If, for example, I have an application-level

[grpc-io] gRPC Java 1.32.1 released

grpc-java v1.32.1 is releasend and available on Maven Central. Note: v1.32.0 was skipped due to release process issues. The tag does exist though and is effectively the same code as present in v1.32.1. API Changes - api: Removed deprecated method ChannelBuilder.blockingExecutor() (#7242

Re: [grpc-io] Client Hung Up In Server Stream

It looks like you are missing p.trySuccess() or p.tryFailure() in the onCompleted() callback. If the server responds with a zero-length stream (no messages), then onNext() won't be called. On Wed, Sep 23, 2020 at 10:07 PM Mahesh Mothukuri < mothukuri.mah...@gmail.com> wrote: > Hi People, > > I'm

Re: [grpc-io] Aggregation/Parallel Asynchronous Calling

On Mon, Sep 21, 2020 at 5:54 AM Nicholas Bunn wrote: > What I am looking for is a way to query all four services in parallel and > wait for a callback or notification from each one once they have completed > their process, and their information is available. Would one be able to > achieve this wi

Re: [grpc-io] Aggregation/Parallel Asynchronous Calling

On Mon, Sep 28, 2020 at 4:19 AM Nicholas Bunn wrote: > That's helped to clear it up quite a bit for me. Is there a particular > reason to avoid sending each RPC call in its own thread? > Not much from gRPC's perspective. Sync vs async APIs can behave a bit differently, depending on how the threa

Re: [grpc-io] Re: Use Cronet underneath GRPC

actually rely on the transport API (I don't primarily work on core so not sure about best practices here). 3) The http/2 client inside of gRPC core is not exposed for use without the RPC layer. Best, Eric On Fri, Sep 18, 2020 at 11:58 AM ashish tiwari wrote: > Thanks for the response!!

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

You need to call `enableRetry()` on the channel builder. See the retry example and example config

Re: [grpc-io] Re: Synchronous and asynchronous waiting in GRPC service methods

You should not use directExecutor. It offers no benefits over the single-thread thread pool for your use-case. I'm writing a lengthier reply. On Wed, Sep 30, 2020 at 11:37 AM 'sanjay...@google.com' via grpc.io < grpc-io@googlegroups.com> wrote: > Sorry, just realized you are using client streamin

Re: [grpc-io] Synchronous and asynchronous waiting in GRPC service methods

On Wed, Sep 30, 2020 at 1:18 AM 'weißnet auchnicht' via grpc.io < grpc-io@googlegroups.com> wrote: > Increasing the thread pool size is probably not a good solution, as it > would always have to be greater than or equal to the number of concurrently > active requests for these 2 methods. > Increa

Re: [grpc-io] Synchronous and asynchronous waiting in GRPC service methods

On Thu, Oct 1, 2020 at 1:04 AM 'weißnet auchnicht' via grpc.io < grpc-io@googlegroups.com> wrote: > Increasing the thread pool size is an *easy* solution and keeps the code >> simple. But yes, it really requires an unbounded thread pool to avoid >> issues, although you could limit the service to 1

[grpc-io] Re: python-speech client library error originating from sync_posix.cc

We haven't been able to gather any further information yet. However, we've decide to use a different testing strategy that ameliorates this issue. Thank you for the detailed help and responses! On Tuesday, October 6, 2020 at 10:03:59 AM UTC-7, Richard Belleville wrote: > > I think that's unlikel

Re: [grpc-io] Adding http response headers

HTTP headers are delivered via Metadata. You will need to use a ClientInterceptor. HttpUtils.newCaptureMetadataInterceptor()

Re: [grpc-io] custom transport grpc java

There's not too much, but we can give you pointers. The transport API is internal and we don't support out-of-tree custom transports. If you have a need for a custom transport, 1) I'd first double-check that there is a serious need, as creating a new transport is involved and 2) would suggest it to

Re: [grpc-io] custom transport grpc java

On Mon, Nov 2, 2020 at 10:39 PM Avinash Lakshman wrote: > I was just looking at this as an academic exercise given the literature > says that the transport is pluggable. > What literature is that? Yes I would be looking at the client and server side. > So transport is pluggable in two ways: 1)

[grpc-io] grpc-java: Dropping support for Java 7

TL;DR: Dropping support for Java 7, but keeping current Android API level. If this causes problems for you, please reply here or comment on the issue. gRPC Java desperately wants Java 8 language features to design more natural APIs and provide more convenience when implementing. Some of our depend

Re: [grpc-io] gRPC-Java v1.34.0 Released

This release appears to have a severe bug that can be triggered for googleapis.com (#7643 ). The bug can be "dormant" and trigger at any point in the future. *Even if you don't see any issues*, please avoid this release if you use gRPC with Google serv

[grpc-io] gRPC Java v1.34.1 Released

gRPC Java 1.34.1 is released and is available on Maven Central. Bug Fixes - core: Fix CompositeChannelCredentials to no longer use CallCredentials for OOB channels. OOB channels are available for load balancing policies to use to c

Re: [grpc-io] gRPC-Java v1.34.0 Released

Dec 8, 2020 at 10:21 AM Eric Anderson wrote: > This release appears to have a severe bug that can be triggered for > googleapis.com (#7643 <https://github.com/grpc/grpc-java/issues/7643>). > The bug can be "dormant" and trigger at any point in the future. *Even if >

Re: [grpc-io] gRPC validation for best-practice security? (CWE-502)

On Wed, Jan 13, 2021 at 4:47 AM Tom Hintz wrote: > What infrastructure is available to validate gRPC messages prior to > deserialization to protect against CWE-502 attacks? Reference: > > MITRE CWE-502 Description > > I wouldn't say there is any

[grpc-io] gRPC-Java v1.35.0 Released

gRPC Java 1.35.0 is released and should be available on Maven Central and JCenter. https://github.com/grpc/grpc-java/releases/tag/v1.35.0 Bug Fixes - core: Fix CompositeChannelCredentials to no longer use CallCredentials for OOB channels. OOB channels are available for load balancing polici

Re: [grpc-io] gRPC validation for best-practice security? (CWE-502)

On Thu, Jan 14, 2021 at 12:21 AM Tom Hintz wrote: > Avoiding selection of arbitrary classes is key to CWE 502, but also the > bounding of arrays and strings (which are a specialized form of array). I don't see any mention of that in CWE 502, but I agree parsing untrusted data needs to be done c

Re: [grpc-io] gRPC-Java method overloading

Assuming that you are asking about overloading the method names defined in your service's proto file, this StackOverflow question and answer addresses this issue: https://stackoverflow.com/questions/65034685/is-it-possible-the-grpc-functions-overloading/65034755#65034755 Thanks, Eric O

Re: [grpc-io] Re: (grpc-java) Detecting client network disconnect and connect

I believe that https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#getState-boolean- and https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#notifyWhenStateChanged-io.grpc.ConnectivityState-java.lang.Runnable- are the APIs that you are looking for. Thanks, Eric

Re: [grpc-io] Anyone adding HTTP/3 support for gRPC?

I *think* there have been some HTTP/3 experiments, but nothing actively being worked on. For mobile though, grpc-java and grpc-objc clients do have support for Cronet, and Cronet supports HTTP/3. Cronet is basically Chrome's networking stack built into a library. There's no server support, but that

[grpc-io] gRFC A36: xDS-Enabled Servers

Please review and comment. The gRFC is at https://github.com/grpc/proposal/pull/214. The gRFC covers new APIs and their plumbing to allow having xDS-enabled servers. The precise C++/wrapped language APIs are not covered, but an idea of what they may look like is covered. Java and Go have their conc

Re: [grpc-io] [grpc-java] ClientInterceptor Order

On Tue, Feb 16, 2021 at 6:38 AM Philippe Laflamme wrote: > > This is true for calls to the ClientCall methods, but is not for calls to > ClientCalls.Listener. The calls to the ClientCall.Listener methods are in > the reverse order as the calls to ClientCall methods. So if both a and b > above "in

[grpc-io] Re: Content-Type not being set

Go is the only implementation to support sending the +format syntax. All other implementations ignore it completely when receiving. On Wednesday, February 17, 2021 at 10:10:21 AM UTC-8 Easwar Swaminathan wrote: > If the gRPC-Go server is crashing, please do file an issue under the > grpc-go re

Re: [grpc-io] [grpc-java] ClientInterceptor Order

On Wed, Feb 17, 2021 at 6:17 PM Philippe Laflamme wrote: > This is 100% the behavior you want; anything else leads to madness. >> Interceptors inject themselves to the boundary because the application and >> the gRPC library and allow you to do "whatever you want" with the API. This >> produces a

<    1   2   3   4   5   6   >