Re: [grpc-io] GRPC client getting error while connecting to service UNAVAILABLE

On Thu, Apr 18, 2024 at 1:28 PM shobhit agarwal wrote: > suddenly it started failing with error:UNAVAILABLE while service was up > and running > What was the error message? -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this gr

Re: [grpc-io] [grpc-Java] Query regarding ping deadline exceeded

On Fri, Apr 12, 2024 at 11:53 AM R Chinmay wrote: > In both cases we receive a generic log with status DEADLINE_EXCEEDED. I see "[grpc-Java]" in the email subject. Are you actually using grpc-java? gRPC Java provides a lot of information in the string part of the status. > 1. Can you provide

Re: [grpc-io] GRPC client getting error while connecting to service UNAVAILABLE

+grpc-io error:UNAVAILABLE isn't a format that grpc-java uses. This may be your own logging. You'll need to find it and include more information from the Status. In particular, status.getDescription() and sometimes getCause() have useful information. On Sat, Apr 20, 2024 at 2:03 AM shobhit agarw

Re: [grpc-io] What is the suggested way to use onError on StreamObserver?

On Sat, Apr 13, 2024 at 9:23 AM Debraj wrote: > I did not quite understand the statement - "*It will respond > with Status.UNKNOWN and interceptors might get confused"* . > > Let's say I do not have the try - catch in the purge() method and I have > a ServerInterceptor like below. > If you reall

Re: [grpc-io] gRPC 1.55 Throughput Drop when Client Send Rate Increase

On Sun, May 12, 2024 at 11:03 AM Yunhao Bai wrote: > When we are performing performance test and try to test the throughput for > the gRPC server, we find there is a very strange behavior: When we increase > the rate for unary RPC call to the gRPC server (e.g., from 15k rps to 50 > rps), we see a

Re: [grpc-io] Error with building io.grpc.ManagedChannelRegistry

The problem here is maven-assembly-plugin breaks SPI "services," because by default it fails to combine some magic files together. This causes the dns name resolver to not be found, and can prevent some transports and load balancers also to not be found. You need to configure it to use the metaInf

[grpc-io] gRPC-Java and Netty 4.1.111 possible corruption

Users of grpc-java should avoid upgrading to Netty 4.1.111 (released two days ago), as it appears there is corruption. The issue is being tracked in https://github.com/grpc/grpc-java/issues/11284 Little is known now, but best to delay the upgrade until more is known. -- You received this message

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

grpc-netty in this release is compatible with Netty 4.1.111; it fixes the incompatibility that caused data corruption. grpc-netty-shaded is still using Netty 4.1.100. New Features - New module grpc-gcp-csm-observability (df8cfe9

[grpc-io] Re: gRPC-Java and Netty 4.1.111 possible corruption

The issue was resolved. It is best to use 1.63.2, 1.64.2, 1.65.1, and later. The earlier versions 1.64.1 and 1.65.0 did fix the corruption, but it is better to use the later versions listed. The corruption was caused by grpc-java code, so would not have impacted other Netty users. Luckily the c

Re: [grpc-io] com.google.protobuf dependency

On Wed, Aug 28, 2024 at 10:34 AM Scott Lewis wrote: > Question: Is grpc going to switch at some point to 4.x of protobuf > library? Or is it going to stay on 3.X of the protobuf-java library? Is > staying on 3.X a matter of backward compatibility? See https://github.com/grpc/grpc-java/issu

Re: [grpc-io] Guarantees on 'completeness' when streaming big data

On Mon, Sep 9, 2024 at 6:23 AM olivier barthelemy < perso.olivier.barthel...@gmail.com> wrote: > But it does not guarantee that "all sent streamed 'parts' will be > received". Correct. RPCs don't have guaranteed delivery. The RPC itself can fail. It also looks like that "The sender will not be

Re: [grpc-io] It seems gRPC's has not support for service discovery & registry so far

On Mon, Jun 13, 2016 at 3:03 AM, Benson Wang wrote: > We register our services by the way below. But we cannot remove the > registered services from gRPC. > If you want to mutate the services after you start the server, you need to provide your own HandlerRegistry. For example, you can pass a Mu

Re: [grpc-io] It seems gRPC's has not support for service discovery & registry so far

On Tue, Jun 14, 2016 at 12:54 AM, Benson Wang wrote: > Thanks Eric for your feedback. Could you give me a clue to use "Name > Resolvers" to integrate with a service discovery? > Implement a NameResolver . We use URI schemes to prim

Re: [grpc-io] Executing listeners using MoreExecutors.directExecutor().

On Tue, Jun 14, 2016 at 5:48 AM, wrote: > Is it safe to execute a listener using MoreExecutors.directExecutor(), as > in > > ListenableFuture res = myFutureStub.myMethod(myRequest); > res.addListener(myCallback, MoreExecutors.directExecutor()); > We actually support it channel-wide with ManagedC

Re: [grpc-io] Is there miss an equls method for class Context.Key in gRPC java

On Thu, Jun 16, 2016 at 6:16 AM, Wang Tao wrote: > private Object lookup(Key key) { > for (int i = 0; i < keyValueEntries.length; i++) { > if (key.equals(keyValueEntries[i][0])) { // here use an equals method? > > It is purposefully using reference equality. In earlier versions we overrode

[grpc-io] gRPC Java 0.14.1 Released

Changes: - Update Netty to v4.1.1.Final, which is the first stable release we've released with. gRPC-java v0.14.0 was already compatible with Netty v4.1.1. This fixes cancellation causing Channel to black hole received data and fixes a DoS bug in renegotiation when using OpenSSL-based

Re: [grpc-io] [grpc-java 0.14.0] gRPC calls not working after a certain period.

On Sat, Jun 25, 2016 at 4:36 AM, Taehyun Park wrote: > I'm using grpc java on Android and I found a very weird issue. After a > certain period a ManagedChannel no longer works. > Was that after a period of inactivity? Were you on good WiFi (one that you trust), bad WiFi, or cellular? I instanti

Re: [grpc-io] [grpc-java 0.14.0] gRPC calls not working after a certain period.

Whew. I saw your email this morning but didn't have time to reply saying I had so clue what could cause that. Glad it's working for you, and you can look forward to built-in idleness. And an hour makes sense for the tcp connection to (silently) break with a home network, since there is a NAT invol

Re: [grpc-io] Java NANO_RUNTIME does not support services

Nano itself doesn't support services, and that's what gRPC does. You just need to pass ignore_services=true to javanano and protoc-gen-grpc-java will generate the services. So you will need this for nano: ignore_services=true And this for grpc (if using earlier that v0.14.0, then it needs to be n

Re: [grpc-io] Simple Sample, bu "An existing connection was forcibly closed by the remote host"

Sorry, I was going to reply with something like that yesterday and things came up. Glad you got it working. It means I can not use ma servezr more than once However, the server shouldn't die even without the awaitTermination(). Future clients should work fine. If not, that's a bug. On Tue, Jun

Re: [grpc-io] Re: Use grpc with Chrome browser

Maybe this is the trailer issue being noted. It doesn't seem exposed for our usage. Comment 14 seems to say as much. On Fri, Jul 8, 2016 at 10:19 AM, 'Carl Mastrangelo' via grpc.io < grpc-io@googlegroups.com> wrote: > Link to the issu

Re: [grpc-io] Building grpc-java on Power8

This is probably similar to a previous discussion . We've not done any work to build the native grpc-java components on Power or ARM (and Android doesn't count, since that stack doesn't need any native components to be built). For

Re: [grpc-io] StatusRuntimeException is threw instead of StatusException for the caller

Exceptions don't exist in grpc; you won't see an exception propagate from server to client. Instead, grpc uses Status, which has a enum "code" and a string "description". StatusRuntimeException and StatusException are part of the stubs to allow using grpc in an idiomatic way in Java. StatusExceptio

Re: [grpc-io] Kerberos

Kerberos is strange in that it authenticates an entire connection, which is counter to HTTP semantics. It currently seems semi-incompatible with HTTP/2, or at least how to do it with HTTP/2 hasn't been specified. Thus gRPC is not currently compatible with Kerberos. On Fri, Jul 15, 2016 at 2:48 PM,

Re: [grpc-io] How to set retry delay after connection failure

What language are you working in? Is there a reason you want at static value? You don't want to just cap the exponential backoff to a lower maximum? On Mon, Jul 18, 2016 at 7:07 AM, wrote: > Right now the retry delay gradually increases. How can i set it to a > static value? > > -- > You receive

Re: [grpc-io] Re: [Question] BlockingResponseStream.hasNext blocks forever

On Tue, Jul 19, 2016 at 12:20 PM, ran.bi via grpc.io < grpc-io@googlegroups.com> wrote: > I don't think that is the problem in my case. > My server is basically like > > for all data > stream.onNext(data) > stream.onComplete() > > I don't see any chance to cause the problem you described. > Hmm

Re: [grpc-io] Load balancing gRPC servers

Both TCP-based LB and HTTP/2-based LB (with HTTP/2 to the backend) work as expected. TCP-based does not work as well with HTTP/2 because the connections last longer than HTTP/1, but it does function. On Wed, Jul 27, 2016 at 6:01 PM, wrote: > In the past I've used haproxy to load balance all sort

Re: [grpc-io] Automatic connection handling?

Dial creates a new connection, but you can share the ClientConn between callers and they will share the connection. We don't automatically pool in Go today. On Tue, Jul 19, 2016 at 3:35 AM, Ewan Walker wrote: > I am using go, and using the normal connection methods built in to the > grpc library

Re: [grpc-io] Re: Load balancing gRPC servers

On Thu, Jul 28, 2016 at 2:52 PM, wrote: > It seem Nginx v1.9.5 supports HTTP/2 > https://www.nginx.com/blog/nginx-1-9-5/ > nginx doesn't support HTTP/2 to the backend yet. That is necessary for gRPC. You may want to take a look at nghttpx. -- You received this message because you are subscrib

Re: [grpc-io] [grpc-java 0.14.0] gRPC calls not working after a certain period.

FYI: 3.0.0-pre1 includes support for auto-idling Channels (and keepalive for OkHttp). So you may be able to simplify your code now. On Sun, Jun 26, 2016 at 1:01 PM, Eric Anderson wrote: > Whew. I saw your email this morning but didn't have time to reply saying I > had so clue what could cause th

Re: [grpc-io] grpc from JavaScript in the browser

I think the comment was saying possible in the theoretical sense. Not possible with code available today. On Mon, Aug 1, 2016 at 7:07 AM, wrote: > From this comment > , > I co

Re: [grpc-io] Re: [Question] BlockingResponseStream.hasNext blocks forever

It looks like isCancelled() is a bit useless right now, since it's value changes too late . Thanks for bringing this to our attention. Sorry it took so long for me to look at it. On Mon, Jul 25, 2016 at 4:55 PM, ran.bi via grpc.io < grpc-io@googlegrou

Re: [grpc-io] Re: [Question] BlockingResponseStream.hasNext blocks forever

Oops. Sorry. Wrong thread. That response is actually for this issue instead. For your actual issue, I'm still wondering what version of grpc-java you're using. Also, are you using any proxy between the client and server? As a shot-in-the-dark, you m

Re: [grpc-io] bazel rules_protobuf (java)

On Sun, Jul 31, 2016 at 6:26 PM, Paul Johnston wrote: > If you are new to http://bazel.io, this might be a good way to try it > out. As it will automatically install the protoc and protoc-gen-grpc-java > binaries into your workspace, it requires no configuration and may be one > of the easier wa

Re: [grpc-io] Re: Load balancing gRPC servers

On Tue, Aug 2, 2016 at 2:36 PM, wrote: > I supposedly managed to implement an nginx proxy to a Node.js app using > HTTP2. It was working well, so I assumed that nginx supports HTTP/2 to the > backend. > Hmm... I may be out-of-date. What configuration did you use? Are you sure it was using HTTP/2

Re: [grpc-io] Re: Best Practise for Android

On Wed, Aug 3, 2016 at 9:45 AM, wrote: > Thanks for the response, I've added deadlines as a start, so my app is > hanging far less. > In v1.0.0-pre1, we now have some new options that may help prevent/detect hangs. If you're having trouble during periods of activity, you can set enableKeepAlive(

Re: [grpc-io] gRPC for low latency Distributed Services

On Mon, Aug 8, 2016 at 12:35 AM, wrote: > With custom zmq messaging bus we get latency in order of microseconds > between 2 services on same host (21 us avg) vs 2 ms avg for gRPC. > Did you reuse the ClientConn between RPCs? In our performance tests on GCE (using not very special machines, wher

Re: [grpc-io] Is there a writeup on how to introduce a new transport layer?

In addition to transport, what language do you want to do it in? On Thu, Aug 4, 2016 at 10:14 AM, wrote: > Title says it all. > I'd like to write a new transport layer and wondering if someone has a > good writeup on how to do it. > > -- > You received this message because you are subscribed to

Re: [grpc-io] Is there a writeup on how to introduce a new transport layer?

InProcess is the smallest transport by far (~500 lines for all the meat of client+server), but it does a poor job of helping you understand the threading model and how to use AbstractStream2[1] and friends. AbstractStream2 is much easier to figure out how to use (vs AbstractStream), but it is stil

Re: [grpc-io] [grpc-java] client-side reconnect

Note that we are aware setting wait for ready is more painful than it should be (you have to use a client interceptor today), due to these two issues. On Thu, Aug 25, 2016 at 3:08 PM, 'Louis Ryan' via g

Re: [grpc-io] Re: grpc-java server-side compression not working/implemented?

I also filed an issue for making an example for server-side. On Wed, Aug 24, 2016 at 9:29 AM, Stephen Haberman < stephen.haber...@gmail.com> wrote: > Cool, issue filed here: > > https://github.com/grpc/grpc-java/issues/2196 > > Thanks! > > - Stephen

Re: [grpc-io] Any success with GRPC and the new AWS Application Load Balancer?

On Sat, Sep 3, 2016 at 6:16 PM, wrote: > 1) With plaintext GRPC on the backend, ALB fails because it tries to > upgrade from HTTP/1.1 which grpc-java does not support. > Yep. It isn't supported. The first request being HTTP/1 makes things... weird. For those following along at home, this issue

Re: [grpc-io] Re: Does OkHttpChannelBuilder work with TLS/NPN protocol for android 4.1.2

Please enable the Google Play Services Dynamic Security Provider. There are a few links to how to do that in our public SECURITY.md . It's my understanding that every Google property should be using the provider for security

Re: [grpc-io] Speech API with browser data

For Google service-specific issues, please start a question on Stack Overflow. In this case it seems you should tag it with google-speech-api. On Wed, Sep 7, 2016 at 9:56 AM, wrote: > > I'm trying to use the Google Speech API Streaming recognition using > browser mic data but im receiving "audio

Re: [grpc-io] Best practice for client channel

You should share a single channel across threads. Only in very heavy throughput (when we start talking about trying to fully saturate a server NIC) should you even begin to consider do something else. I can't say what bug you experienced before, but only doing one RPC on each channel at a time is

Re: [grpc-io] Re: Correct GRPC Server configuration for low latency and high throughput

And to be clear: the blocking API is just as fast as async API, but your application can't scale as much with the blocking API because your application must have a thread per RPC. Your test is a ping-pong latency test, since it waits for one RPC to complete before starting the next. In no way does

Re: [grpc-io] Best practice for client channel

Reading another thread made me want to tweak my statement: > > Only in very heavy throughput (when we start talking about trying to fully > saturate a server NIC) should you even begin to consider do something else. Even in that case you probably shouldn't use multiple Channels. Instead, you woul

Re: [grpc-io] [grpc-java 0.14.0] gRPC calls not working after a certain period.

Catching up on old threads... It sends a GO_AWAY packet when the status is changed to IDLE. Do I have to > release this channel or is it safe to reuse this channel? If I can reuse > the channel, it looks like I no longer need to release the channel. The channel should have been safe to reuse. Wh

Re: [grpc-io] Strategy for distributing protobuf APIs

On Fri, Aug 26, 2016 at 7:51 AM, Mario Steinhoff wrote: > Currently, I am not distributing the proto file but compile the proto > file into Java classes and create a JAR file in the service A build. > The JAR file gets publishes to my internal artifact repository but > without grpc-stub and grpc-

Re: [grpc-io] [grpc-java 0.14.0] gRPC calls not working after a certain period.

On Sat, Sep 17, 2016 at 12:40 AM, wrote: > I lazily create my stub, so I've tried checking if stub is disconnected, > and creating a new one in that case, but I'm still not winning. Is there > some solution that you or anyone else could suggest? > The channel itself is lazy, so you could just cr

[grpc-io] Re: Generated OuterClass has a lot of incompatibilities !

This was resolved in https://github.com/grpc/grpc-java/issues/2300. There was an older protobuf getting included in the application, which was causing trouble. On Monday, September 26, 2016 at 8:51:04 AM UTC-7, Smallufo Huang wrote: > > Hi , I am new to gRPC / protobuf. > This is my first .proto

[grpc-io] gRPC Java 1.0.1 Released

Changes: - Moved io.grpc.Context and io.grpc.Deadline from grpc-core to its own artifact, grpc-context. This is to allow wider usage of the API and avoid circular dependencies. grpc-core depends on the new artifact. (#2226) - Avoid creating unnecessary threads in InProcess transport, w

Re: [grpc-io] [grpc-java 1.0.0] Use grpc in production causes memory leak

If you have high direct memory usage, typically it isn't a memory leak and instead is caused by excessive buffering due to the application sending too many RPCs concurrently (e.g., you send 1000 1MB RPCs simultaneously) or ignoring flow control (isReady/onReady when using streaming). Could you be c

Re: [grpc-io] [grpc-java] Limit message size for uncompressed grpc requests

maxMessageSize applies to both uncompressed and compressed sizes. This is the check that applies to the on-the-wire size, independent of whether the message is compressed. It seems you are

Re: [grpc-io] [howto] stream auto reconnect ?

When you receive the error on the client-side, the stream is dead. You should simply create a new RPC using the same Stub/Channel. The Channel will automatically create a new connection to the server, but it can't re-establish any streams. When load balancing and proxies are involved, a particular

Re: [grpc-io] Pointless for server to stay behind load balancer?

The tracking issue is https://github.com/grpc/grpc/issues/7957 . The first resolution (#1) would be to add a timer to the server to send a GOAWAY after the connection is a certain age, allowing the proxy to choose another backend. I have an open question in that issue whether we also need an optio

Re: [grpc-io] Re: Java -server -> client blocking queue?

You can check out my "example" in issue 2247 . On Fri, Oct 28, 2016 at 8:32 AM, Matt Mitchell wrote: > So if I'm emitting a stream from my server, should I be checking isReady() > before each onNext() call? > You should check

Re: [grpc-io] [grpc-java] How to close stream by client for server-side streaming

Blocking stub observers thread interruption; if the thread is interrupted it will cancel the RPC. For async stub, you can create a CancellableContext and cancel it: CancellableContext withCancellation = Context.current().withCancellation(); withCancellation.run(new Runnable() { @Override public

Re: [grpc-io] Re: [grpc-java 1.0.0] Use grpc in production causes memory leak

Craig filed issue 2358 . Resolution will be discussed there. On Fri, Oct 21, 2016 at 1:39 AM, Taehyun Park wrote: > Thank you for this information! I will use Netty 4.1.6.Final to resolve > this issue. > > > On Thursday, October 20, 2016 at 10:36:31

Re: [grpc-io] How can use google.protobuf.Empty in Android with protobuf-lite?

Does the snippet in issue 1889 work for you? On Tue, Nov 22, 2016 at 11:27 PM, Wang Tao wrote: > Dear team, > > How can use google.protobuf.Empty in Android with protobuf-lite? > > -- > You received this message because you

Re: [grpc-io] viability of using gRPC to replace our existing RPC framework

On Thu, Dec 1, 2016 at 3:40 PM, Arpit Baldeva wrote: > 1. *Detecting a dead client on server:* Is there a way or recommended > mechanism to detect a client who is no longer connected to the server after > an abrupt client shutdown? In our current framework, we get a TCP level > disconnect which t

Re: [grpc-io] Protobuf - Java

The java_out just enables Java codegen, not grpc-java codegen. You need to use protoc-gen-grpc-java as well. I'd *highly *recommend using the gradle/maven protoc plugins that we document in our main README . If you really want to run protoc m

[grpc-io] gRPC Java v1.0.3 released

The v1.0.3 release has a small bugfix and experimental support for forward proxies. Only users of InProcess transport in tests or users wanting to test the forward proxy support benefit from the update. - Remove a usage of an executor which was just to avoid lock ordering issues. Now the wor

[grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

The Java implementation is going to have hurdles. I sort of expect issues adhering to the design as precisely as it is defined. I've got to figure out where ProxySelector fits into all of this. Any references to "load balancing

Re: [grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

On Wed, Jan 25, 2017 at 2:00 PM, Mark D. Roth wrote: > On Wed, Jan 25, 2017 at 12:59 PM, 'Eric Anderson' via grpc.io < > grpc-io@googlegroups.com> wrote: > >> The Java implementation is going to have hurdles. I sort of expect issues >> adhering to the desig

Re: [grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

On Thu, Jan 26, 2017 at 8:42 AM, 'Mark D. Roth' via grpc.io < grpc-io@googlegroups.com> wrote: > >- *All* requests must go through the proxy, both for internal and > external servers. This is not true. It only applies to external servers. It directly contradicts the earl

Re: [grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

On Wed, Jan 25, 2017 at 5:40 PM, Julien Boeuf wrote: > I think "when it sees the proxy address" also has fundamental issues, like >> requiring the proxy to have a hard-coded stable IP. That means you couldn't >> add a new proxy to the rotation if experiencing too much load. >> >> More likely, in

Re: [grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

On Thu, Jan 26, 2017 at 12:46 PM, Mark D. Roth wrote: > I've attempted to modify the language in the doc to make it clear that the > intent is for outbound traffic to go through the proxy, but that this is > often implemented by having *all* traffic go through the proxy. Please > let me know if

Re: [grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

On Fri, Jan 27, 2017 at 12:16 PM, 'Mark D. Roth' via grpc.io < grpc-io@googlegroups.com> wrote: > Yes. And that seems to agree with how the different proxy choosing logic >> will work; the first primarily consumes hostnames and returns proxy >> hostnames (which is http_proxy in C) and the second o

Re: [grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

On Fri, Jan 27, 2017 at 3:41 PM, Mark D. Roth wrote: > On Fri, Jan 27, 2017 at 1:31 PM, Eric Anderson wrote: >> >> Case 3 as stated today (for contrasting) >> >>1. client wants to connect to service.example.com >>2. do DNS SRV resolution for _grpclb._tcp.service.example.com; you >>fi

Re: [grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

On Fri, Jan 27, 2017 at 4:20 PM, Julien Boeuf wrote: > Keep in mind that in case 3, the grpclb load balancers and the server >> backends are in the same internal domain, with the same access >> restrictions. If we can't use a reverse proxy to access the server >> backends, I don't think we'll be

Re: [grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

On Tue, Jan 31, 2017 at 10:25 AM, Mark D. Roth wrote: > > So I think this leaves us with the current design. > This solution wasn't shown to be lacking: As another alternative, why not fix all of case 1 and support programmatic configuration, in addition to http_proxy? What would be wrong with

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

I'd feel better if there was an example that did not use delimiterCharacter (the value of the field referenced by payloadFieldName is not mutated). Note that for streaming RPCs, we extract headers only from the first > request message on the stream. This seems to imply a change in the semantic

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

On Wednesday, February 1, 2017 at 8:52:57 AM UTC-8, Mark D. Roth wrote: > > What character encoding do they use for that field, UTF-8? How can we >>> tell what character encoding is in use? I think we'd need some way to >>> figure this out in order to support it. >>> >> >> it is raw bytes, so n

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

On Wed, Feb 1, 2017 at 9:38 AM, Mark D. Roth wrote: > Right off the cuff, I can think of a few possible options here: > > 1. Always base64-encode the extracted values. > 2. Do base64 encoding only when non-ASCII characters are actually present. > 3. Simply strip out non-ASCII characters. > There

Re: [grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

On Wed, Feb 1, 2017 at 8:57 AM, Mark D. Roth wrote: > On Tue, Jan 31, 2017 at 12:43 PM, Eric Anderson wrote: > >> >> A more concrete flow: >> >>1. client wants to connect to service.example.com >>2. check whether service.example.com should use a proxy. It shouldn't >>3. do DNS SRV re

Re: [grpc-io] Re: gRFC A1: HTTP CONNECT proxy support

On Wed, Feb 1, 2017 at 10:16 AM, Mark D. Roth wrote: > > Do we know that there are cases where we'll need to support this? I don't > doubt that there are cases where only connections to external servers > should go through the proxy, but I wonder how many cases there are where > users will need t

Re: [grpc-io] gRPC A6: Retries

On Mon, Feb 27, 2017 at 8:53 AM, 'Mark D. Roth' via grpc.io < grpc-io@googlegroups.com> wrote: > While talking with Craig on Friday, we realized that we need to make the > wire protocol a bit stricter in order to implement retries. > > Currently, the spec allows status to be sent either as part of

Re: [grpc-io] gRPC A6: Retries

On Wed, Mar 1, 2017 at 10:20 AM, Eric Anderson wrote: > On Mon, Feb 27, 2017 at 8:53 AM, 'Mark D. Roth' via grpc.io < > grpc-io@googlegroups.com> wrote: > >> However, as per the When Retries are Valid >>

Re: [grpc-io] gRPC A6: Retries

On Wed, Mar 1, 2017 at 10:51 AM, 'Mark D. Roth' via grpc.io < grpc-io@googlegroups.com> wrote: > On Wed, Mar 1, 2017 at 10:20 AM, 'Eric Anderson' via grpc.io < > grpc-io@googlegroups.com> wrote: > >> What? That does not seem to be a proper under

Re: [grpc-io] gRPC A6: Retries

On Thu, Mar 2, 2017 at 8:38 AM, Mark D. Roth wrote: > On Thu, Mar 2, 2017 at 8:24 AM, Eric Gribkoff > wrote: > >> On Thu, Mar 2, 2017 at 8:15 AM, Mark D. Roth wrote: >>> >>> I agree that we don't need to say anything about whether or not the >>> server delays sending Response-Headers until a me

Re: [grpc-io] gRPC A6: Retries

On Thu, Mar 2, 2017 at 9:24 AM, Mark D. Roth wrote: > On Thu, Mar 2, 2017 at 9:13 AM, Eric Gribkoff > wrote: > >> On Thu, Mar 2, 2017 at 9:03 AM, 'Eric Anderson' via grpc.io < >> grpc-io@googlegroups.com> wrote: >> >>> The language is still

Re: [grpc-io] gRPC A6: Retries

The spec was updated today to say: > gRPC servers *must* delay sending Response-Headers until the server's > first response (a Length-Prefixed-Message) is to be sent on the stream. Why is this *must*? It was changed from *should*, so this seems intentional. Java can't support *must*. On Thu, Ma

Re: [grpc-io] gRPC A6: Retries

On Thu, Mar 2, 2017 at 4:46 PM, Eric Gribkoff wrote: > Your quote is missing the first part of the sentence. > > To avoid unnecessarily committing an RPC on the client, gRPC servers >> *must* delay sending Response-Headers until the server's first response >> (a Length-Prefixed-Message) is to be

Re: [grpc-io] gRPC A6: Retries

On Thu, Mar 2, 2017 at 7:44 PM, 'Eric Gribkoff' via grpc.io < grpc-io@googlegroups.com> wrote: > > gRPC servers should delay the Response-Headers until the first response >> message or until the application code chooses to send headers. If the >> application code closes the stream with an error be

Re: [grpc-io] gRPC A6: Retries

I see that retries add the x-grpc-retry-pushback-ms and x-grpc-retry-attempts metadata keys. Is there a reason to prefix them with the x-, even though the rest of the grpc keys just use the grpc- prefix? I didn't see any discussion on that. I also saw this in the spec: > The value for this field

[grpc-io] Re: gRPC Java 1.2.0 Released

On Wednesday, March 15, 2017 at 5:15:41 PM UTC-7, Carl Mastrangelo wrote: > > >- Fixed an error when using keep alives with Netty (#2729 >) > > A further issue was discovered with keepalives with Netty; the feature is still broken (#2828

Re: [grpc-io] Message-Type in gRPC Requests/Responses

I don't think any implementation is providing that header at this point. That would also explain why it isn't defined for responses. On Wed, Mar 22, 2017 at 1:15 PM, Martin G wrote: > Hello, > > According to the wire specification (http://www.grpc.io/docs/ > guides/wire.html) the request can car

Re: [grpc-io] Re: Can more than one grpc service run in a single process?

On Tue, Mar 21, 2017 at 3:23 AM, wrote: > > For C++ gRPC I do not currently see any option for this, I cannot add more > than one service in builder.RegisterService. > Is there some other way to do this > It's not polite to resurrect really old threads. In the future, creating a new thread and ju

Re: [grpc-io] [android][java][cloud-speech] how can I know about the channel status?

On Sun, Mar 26, 2017 at 9:28 AM, David Edery wrote: > 500ms is too much for my app to wait before streaming. This is why I > prepare everything before and I make sure that at the end of a recognition > operation the full structure is prepared for the next iteration. ManagedChannel connects lazi

Re: [grpc-io] Re: Can more than one grpc service run in a single process?

On Wed, Mar 22, 2017 at 11:09 PM, wrote: > On Thursday, March 23, 2017 at 11:27:49 AM UTC+5:30, falco...@gmail.com > wrote: >> >> Hey Eric. He asked about the C++ API and not C# :) I didn't answer since >> I don't know the C++ API. > > I don't know where I saw C#, but I did realize that the Regis

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

On Wed, Mar 29, 2017 at 10:10 AM, 'Craig Tiller' via grpc.io < grpc-io@googlegroups.com> wrote: > I've created a gRFC here https://github.com/grpc/proposal/pull/19 for a > protocol change to allow -bin metadata elements to be transmitted in binary > form. > The proposal LGTM. I made some comments

Re: [grpc-io] [android][java][cloud-speech] how can I know about the channel status?

On Mon, Mar 27, 2017 at 10:11 PM, David Edery wrote: > 4. Create a request observer (of type > StreamObserver) > by calling the speech client's (which is of type SpeechGrpc.SpeechStub) > streamingRecognize function > > I didn't get into the details (yet) but I'm sure that there's network > activ

[grpc-io] Re: grpc-java server-side max age

On Thursday, April 6, 2017 at 9:11:28 AM UTC-7, dan@rach.io wrote: > > In this comment Eric mentions work on a "max age" field server-side in > grpc-java: > https://github.com/grpc/grpc/issues/7957#issuecomment-289515839 > > I can't find any other mention of this. Is there a tracking issue

Re: [grpc-io] grpc-java graceful channel shutdown

+zhangkun, as FYI for RoundRobinLoadBalancer On Tue, Apr 4, 2017 at 7:05 PM, wrote: > Is there a way to command a channel to gracefully shutdown, waiting for > any active calls to complete before terminating the link? > I expected channel.shutdown() to work this way. > That's how it's intended.

Re: [grpc-io] Using gRPC and Thrift together?

We discussed on IRC https://botbot.me/freenode/grpc/2017-04-14/?msg=84026117&page=1 On Fri, Apr 14, 2017 at 12:11 PM, Abhishek Pandey wrote: > Hello, i need to ask can is use gRPC and thrift together, this more of a > architectural question. Can my be producer be in gRPC and receiver in > Thrif

Re: [grpc-io] [android][java][cloud-speech] how can I know about the channel status?

On Mon, Apr 17, 2017 at 10:16 PM, David Edery wrote: > ping :) > You didn't include me in the to: in your reply, so it got lost in the noise. > On Tuesday, April 4, 2017 at 9:14:45 AM UTC+3, David Edery wrote: >> >> On Friday, March 31, 2017 at 10:49:32 PM UTC+3, Eric Anderson wrote: >>> >>> O

Re: [grpc-io] convention related to creating v2 endpoints for grpc services ?

To begin, have the API version in the protobuf package name. That allows you to have the new and old APIs in the same binary. If you can then implement the v1 API using the v2 API it reduces the maintenance burden. If the two APIs are different enough that you can't implement v1 in v2, then yes, yo

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

Also, how did you get those reconnect attempt times? All languages should be following our standard connection backoff algorithm . If one's not, that would be a bug. Note that 20s is permitted as a minimum connect time. Basically,

[grpc-io] grpc-java users: Netty meetup, May 3rd in SF

I'll be presenting at the Netty meetup on May 3rd in San Francisco about API lessons learned with HTTP/2 in Netty. There's been discussions in the past about mixing grpc-java with other Netty Handlers on the same Netty Channel. The talk discusses the Netty cha

  1   2   3   4   5   >