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 .

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

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] 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

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

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.

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

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

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: 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

[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

[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

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

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

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

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.

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 >

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. >>

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] 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] 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

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

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! > > -

[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

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

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

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

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()

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

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

[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

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.

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

[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] 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

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/ >

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

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

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

We discussed on IRC https://botbot.me/freenode/grpc/2017-04-14/?msg=84026117=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

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. >

[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

[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 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

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,

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,

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.

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

On Sun, Apr 23, 2017 at 7:17 AM, David Edery wrote: > There's another, probably-unrelated issue of a channel that reached the streaming limitation - If I stream more than 65 seconds using the same channel, I get an exception. I assume that the source of

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

I'd generally recommend against trying to do that, simply because it would only work in a very limited set of situations. Also, using a middleware doesn't actually gain you anything since the logic is probably method-specific. Middleware is good for cross-cutting features that are mostly

Re: [grpc-io] Differences/considerations between server implementations?

Use the language that fits your use-case best. The only language that is "special" is C++, because it is being optimized to a level beyond most other languages, but at a cost of being harder to use to get all that performance. Python, Java, and Go each use a different stack (Python uses the C

Re: [grpc-io] [Java] Override authority

Ah, then ManagedChannelBuilder.overrideAuthority() seems to be what you want. Linkerd is acting as a reverse proxy, so it "is" the server as far as gRPC is concerned. Your environment could have been configured by overriding DNS to point to linkerd; that's functionally similar to using

Re: [grpc-io] [Java] Override authority

On Wed, Aug 9, 2017 at 1:56 PM, wrote: > What's the right way to override authority for a channel or stub? > > I see there is withAuthority method in CallOptions, but there is no > withAuthority method in AbstractStub and I cannot pass CallOptions to > generated stubs. >

Re: [grpc-io] Question about fallover setup in grpc

I think you can do this with a server interceptor. Simply delay calling next until the configuration is available. On Tue, Aug 1, 2017 at 2:22 AM, Carfield Yim wrote: > Hi all > > I've a server process develop using grpc, I would like to have a cool DR > which receive

Re: [grpc-io] [Java] Netty transport use HTTP1?

Using HTTP/1 in Netty for gRPC is not currently feasible. It's effectively a rewrite. You need to use the TCP-based mode for those load balancers (any that don't support HTTP/2 to the backend). You probably want to use NettyServerBuilder.maxConnectionAge and NettyServerBuilder.keepAliveTime to

[grpc-io] Re: Incompatibility between grpc 1.3.0 and grpc-java's OkHttp

Thank you everyone for waiting as we handled the incompatibility. On further investigation, *we believe few users in production would have experienced the incompatibility*, as anyone with an L7 proxy (i.e., nghttpx) would avoid the direct incompatibility. The OkHttp transport is still broken and

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

On Thu, Jul 6, 2017 at 9:17 AM, Eric Anderson wrote: > OkHttp transport users on v1.3.0 are strongly encouraged to upgrade for > the SETTINGS handling fix. > Actually, all users on v1.3.0 *or earlier* are strongly encouraged to upgrade to v1.3.1 or higher. We understand you

Re: [grpc-io] Re: How to use grpc in karaf(osgi)?

The open issue is https://github.com/grpc/grpc-java/issues/2727 . As I mention in the issue, we really don't have OSGi experience. On Thu, Jul 20, 2017 at 12:27 PM, 'Carl Mastrangelo' via grpc.io < grpc-io@googlegroups.com> wrote: > Osgi has problems with gRPC because io.grpc.Context is not in

Re: [grpc-io] [grpc-java] Get custom method option from interceptors

https://github.com/grpc/grpc-java/pull/3086 will add the details to gRPC's MethodDescriptor as well. It also adds ProtoServiceDescriptorSupplier and ProtoMethodDescriptorSupplier for convenience. (The schema object in the service implements the file and service descriptor suppliers, the schema

Re: [grpc-io] [Java] Clean way to detect client crash

On Mon, Jul 10, 2017 at 6:03 AM, wrote: > We are using grpc for C# <-> Java integration. The C# client application > will start the Java process containing the grpc server, and then create a > Chanel used for calling methods on Java server side. > > One problem we

[grpc-io] gRPC Java v1.3.1 Released

The artifacts are already available on Maven Central and indexed by search.maven.org. OkHttp transport users on v1.3.0 are strongly encouraged to upgrade for the SETTINGS handling fix. Backports from v1.4.0: - OkHttp now ignores unknown SETTINGS. This resolves an important incompatibility

Re: [grpc-io] Re: Is ServerCall#close guaranteed to be called for each RPC?

On Mon, Jun 26, 2017 at 4:10 PM, Ran Bi wrote: > I was under the impression that ServerCall.close also handle the > cancellation because CANCELLED is declared in Status.Code. > Why is cancelation handled specially from other status? > close() is for an application to tell

Re: [grpc-io] Use JKS (Java KeyStore) file rather than key + cert for grpc-java ssl encryption

If you want to use TLS client certificates or the server's certificate isn't trusted by the default root (i.e.., it is self signed or you've made your own certificate authority), then yes. But most of the time you don't need to specify an sslContext on client-side and just let gRPC use its

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

I'm talking about the connection >> retry, not an RPC retry. Also, the server is on a UNIX socket (unix:/path). >> >> >> On Tue, Apr 18, 2017 at 4:01 PM, 'Eric Anderson' via grpc.io < >> grp...@googlegroups.com> wrote: >> >>> Also, how

Re: [grpc-io] Re: How to set TOS bits on grpc server side for a new grpc client connection request?

I assumed this is Go, given lis.Accept(). On Tue, Apr 25, 2017 at 5:14 PM, 'Yang Gao' via grpc.io < grpc-io@googlegroups.com> wrote: > What language are you using? > > On Tuesday, April 18, 2017 at 4:30:24 PM UTC-7, Steven Jiang wrote: >> >> grpc server is listening on a port and accepting

[grpc-io] gRFC A9: Server-side connection management

Discussion for https://github.com/grpc/proposal/pull/23 to have configuration for a variety of server-side connections management. This is for cleaning up connections and forcing new ones for L4 load balancers. Like A8 (but to a lesser degree), this design also pre-dated the gRFC process. --

[grpc-io] gRFC A8: Client-side keepalive

Discussion for https://github.com/grpc/proposal/pull/22 to perform HTTP/2 PING-based keepalives, and permitting aggressive-enough settings to be used as a weak form of health checking. This is actually a really old design and predates the gRFC process, but implementation was delayed and I was

Re: [grpc-io] How can I know which client's connection is lost on server side during stream connection?

On Tue, Apr 25, 2017 at 7:04 AM, 黄骐 wrote: > When client make the first connect, I save the responseStreamObserver > and link it with the client's user ID, > so the server can use the StreamObserver when needs to push message to > client. > That sounds good. But now I

Re: [grpc-io] Use JKS (Java KeyStore) file rather than key + cert for grpc-java ssl encryption

Make a KeyManagerFactory for the JKS and then pass it to gRPC with something like this: NettyChannelBuilder.forPort(0) .sslContext(GrpcSslContexts.configure(SslContextBuilder.forServer(keyManagerFactory)).build()) .build(); SslContextBuilder is from Netty. On Tue, Apr 25, 2017 at 11:55 AM,

Re: [grpc-io] [Java] Clean way to detect client crash

On Wed, Jul 12, 2017 at 2:59 AM, wrote: > Thanks for your idea. Here is how I have implemented it, tell me if this > is correct: > Yeah. That looked good. Why would have to enable keepalive? > If a connection doesn't have any writes then TCP won't be able to

Re: [grpc-io] Re: Java http/2 proxy to backend gRPC services

On Fri, Aug 18, 2017 at 5:11 AM, wrote: > Having said that though, have you used nghttpx with gRPC before? > nghttpx is the go-to proxy with gRPC. Envoy and Istio are both built on top of it (or at least nghttp2; it's basically the same thing). On Friday, August

Re: [grpc-io] grpc, HTTP/2 and corporate firewalls

For those who didn't see the IRC conversation , MITM proxies (those that decrypt the TLS and reencode) would likely cause trouble for gRPC. If websockets over TLS were broken in an environment, I'd expect gRPC to also be broken. While I

[grpc-io] Re: onStreamAllocated was not called, but it seems the stream is active Error

This is a bug in gRPC. That exception is checking our internal state and somehow it's gotten confused. I filed https://github.com/grpc/grpc-java/issues/3007 for tracking On Mon, May 15, 2017 at 3:43 PM, Carl Mastrangelo wrote: > +Eric > > > On Saturday, May 13, 2017 at

Re: [grpc-io] How can gRPC client know about network loss/failure?

On Wed, Jun 21, 2017 at 3:10 AM, wrote: > Hi Eric, thanks for the response but i have to problems > 1) I am using grpc-java 1.0.1 which does not support this Interface (The > product team has decided on grpc version) > Sorry, but the feature wasn't available in

Re: [grpc-io] [grpc-go] why use independent goroutine keepalive rather then conn.setReadDeadline?

When the keepalive timer expires (and there's been no activity; most expirations will have activity and so it will just re-set the timer), the connection isn't killed. Instead, a *write* is done on the connection. If a read happens within the timeout, then everything is deemed good and it waits

Re: [grpc-io] Re: GRPC calls over a proxy

Since 1.1, C-derived languages (which includes C#) can specify the http_proxy environment variable and gRPC will use HTTP's CONNECT to tunnel through the proxy. On Wed, Jun 14, 2017 at 9:42 AM, 'Jeffrey Rennie (SurferJeff)' via grpc.io < grpc-io@googlegroups.com> wrote: > Since no one replied in

Re: [grpc-io] [gRPC-go]Is any best practice for multi-conn per one endpoint?

You can create multiple channels to increase concurrency. Although if you are hitting MAX_CONCURRENT_STREAMS limits it would be important to make sure the additional channels connect to a different server, otherwise what is the point of MAX_CONCURRENT_STREAMS? Also, you should make sure your

Re: [grpc-io] How can gRPC client know about network loss/failure?

You want to enable keep alive, via keepAliveTime on NettyChannelBuilder or OkHttpChannelBuilder. On Sun, Jun 11, 2017 at 10:54 PM, wrote: > > I have a gRPC server to whom i have connected my gRPC client (Java). > - the client is observing server streaming RPC, which

Re: [grpc-io] Behaviour of CallStreamObserver.isReady [grpc-java]

Is your RPC a client-streaming or bidirectional RPC? If not, you're not going to see much benefit from isReady on client-side. isReady() will become true before the server actually sees the RPC. There is buffering done in gRPC to allow for adequate throughput, so the isReady() is not precisely

Re: [grpc-io] Subject Alternate Names problem in SSL connection

Julien, do you know the expected behavior after PR#5666 ? On Tue, Jun 13, 2017 at 1:20 PM, AK wrote: > Following one of group member's help as below I was able to create SSL/TLS > based client-server. > > You need to mint the

Re: [grpc-io] Re: Limiting number of pendingStreams (maxConcurrentCallsPerConnection)

For unary calls, I don't think there is a pre-existing solution for you. Streaming RPCs that observe flow control (isReady()) will naturally avoid sending (except for headers) when MAX_CONCURRENT_STREAMS is reached. But unary calls already have their request at the time of the call, and in neither

Re: [grpc-io] Grpc.Core.RpcException method is unimplemented with C# client and Java Server

nm. I see you figured out the solution on StackOverflow . Yes, service implementations don't call super, since the default responds with UNIMPLEMENTED. On Mon, May 22, 2017 at 1:41 PM, Eric Anderson wrote: > On Sun, May 21, 2017 at

Re: [grpc-io] Grpc.Core.RpcException method is unimplemented with C# client and Java Server

On Sun, May 21, 2017 at 2:45 PM, wrote: > Grpc.Core.RpcException Status(StatusCode=Unimplemented, Detail="Method > tourism.RemoteService/Login is unimplemented"). The server receives the > request but does not have time to respond and throws: > > INFO: Request from ex@ex.comMay

Re: [grpc-io] grpc-go: How to tie data to the lifetime of the underlying transport?

On Fri, May 19, 2017 at 3:22 PM, Benoit Sigoure wrote: > In Foo(), I authenticate the client using a user/password passed as > metadata before executing the FooRequest. Authenticating the client > each time is expensive, so I want to remember somewhere that I already >

Re: [grpc-io] Java backpressure is ... strange

On Tue, May 23, 2017 at 9:22 PM, Ryan Michela wrote: > This API seems backwards. Why is the response observer responsible for > managing the request observer's flow control? > Ah, yes. In short: "because that is the only object grpc creates". "History" could also be a

[grpc-io] Incompatibility between grpc 1.3.0 and grpc-java's OkHttp

If you have grpc-java OkHttp clients, avoid upgrading to 1.3.0 for any of the C-based languages. We've been notified of an incompatibility. We will be working to fix grpc-java and figure out a fix for

Re: [grpc-io] [gRPC Java] : Long time async Server streaming RPCs

In both scenarios you are covered. Do recognize that streams *will* eventually die, so you should plan on reconnecting them. But they can last for a long time. Depending on your network, you may also want to enable keepalive via NettyChannelBuilder.keepAliveTime. You'll want to use the async stub

Re: [grpc-io] Re: grpc streaming and loadbalancer close connections?

When you can, use ManagedChannelBuilder. It will auto-choose which transport, so Netty vs OkHttp, and has a stable API. We provide more advanced options in NettyChannelBuilder but it isn't a stable API. You should be able to use both TLS and plaintext with ManagedChannelBuilder. On Tue, May 30,

Re: [grpc-io] Java backpressure is ... strange

ClientCallStreamObserver.isReady() stays true for the > remainder of the stream. > > Are these differences intentional? > > > On Wed, May 24, 2017 at 10:05 AM, 'Eric Anderson' via grpc.io < > grpc-io@googlegroups.com> wrote: > >> On Tue, May 23, 2017 at 9:22 PM, Ryan Michela

Re: [grpc-io] java keep alive WARNING: Received GOAWAY with ENHANCE_YOUR_CALM

In 1.3 we started allowing clients to be more aggressive. From the 1.3 release notes: "Keepalives in Netty and OkHttp now allow sending pings without outstanding RPCs. The minimum keepalive time was also reduced from 1 minute to 10 seconds. Clients must get permission from the services they use

Re: [grpc-io] [grpc-core] How grpc channel retry the connection?

You shouldn't need to do anything. The channel will automatically attempt to reconnect on later RPCs. If connecting fails, it will use exponential backoff. When you initially create the channel, it doesn't eagerly create a connection. It is only after requesting RPCs that it makes a connection.

Re: [grpc-io] grpc over SOCKS

On Tue, Sep 12, 2017 at 6:17 PM, neeleshk via grpc.io < grpc-io@googlegroups.com> wrote: > Has there been any change to this or is it that there are still no gRPC > client implementations that support SOCKS/other proxies? > At this point I believe all the implementations support client-side

Re: [grpc-io] [java] Challenge-Response / Digest Auth for GRPC

On Mon, Sep 18, 2017 at 3:51 AM, William Shallum wrote: > * Is this a good way of doing challenge/response over GRPC? > Yeah, an interceptor seems like a good approach. > * Is it possible in the Java API to have an interceptor that can retry > requests transparently? >

Re: [grpc-io] Outgoing port on gRPC Java client

On Tue, Sep 19, 2017 at 8:48 PM, wrote: > 1) how does the gRPC Java client select the outgoing TCP port?? What are > the default ports is any?? > Like virtually every other TCP client, the OS selects an unused port in the OS's ephemeral range

Re: [grpc-io] [grpc-core] How grpc channel retry the connection?

在 2017年9月21日星期四 UTC-7上午11:09:49，yihao yang写道： > > I guess the default wait_for_ready option is just to wait the exponential > backoff reconnect until it timeouts and will not issue the channel > reconnect immediately. Am I right? Yes, the wait_for_ready says you'd rather wait than get a failed

Re: [grpc-io] Re: Trying to get a basic Google Cloud Endpoints gRPC project working with an OAuth2.0 auth provider

"version 1" was already likely using JWT. gRPC's MoreCallCredentials.from() tries to convert any ServiceAccountCredentials to a ServiceAccountJwtAccessCredentials. This is possible as long as there aren't scopes set. "version 1"'s failure of "PERMISSION_DENIED: JWT validation failed: Audience not

Re: [grpc-io] Re: Trying to get a basic Google Cloud Endpoints gRPC project working with an OAuth2.0 auth provider

On Fri, Aug 25, 2017 at 6:02 AM, julie wrote: > So instead of the audience (SERVICE_CONFIGURATION_NAME) that we set, we > are obtaining a string like : https://35.195.24.28:80/reporter.Reporter > > JWT's audience is set based on the Channel's host. You need to use a

Re: [grpc-io] Re: Trying to get a basic Google Cloud Endpoints gRPC project working with an OAuth2.0 auth provider

On Wed, Aug 30, 2017 at 2:42 AM, wrote: > Btw, would it be possible to have the gRPC client on > AppEngine? ManagedChannelBuilder is not supported in AppEngine restricted > environment. > GAE Java 7 *should* work with the OkHttp transport. However, I believe there was a

Re: [grpc-io] Re: (golang) Detecting a dead client

On Wed, Aug 30, 2017 at 1:39 AM, wrote: > Was the heartbeat solution ever implemented? > See https://godoc.org/google.golang.org/grpc#KeepaliveParams . ServerParameters.Time and Timeout. -- You received this message because you are subscribed to the Google Groups

Re: [grpc-io] Re: Trying to get a basic Google Cloud Endpoints gRPC project working with an OAuth2.0 auth provider

+julien, in case he's more familiar with ESP's different JWT audience (some docs ) On Wed, Aug 30, 2017 at 1:57 PM, wrote: > even if we set domain

Re: [grpc-io] Java client get server TLS certificate from a StreamObserver connection.

On Tue, Sep 5, 2017 at 1:07 PM, wrote: > Is there a means for the client to obtain the certificate bytes from the > TLS negotiation that was sent by the server ? The reason I ask, to avoid a > replay security scenario the idea is for the client to hash this and send > it back

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

On Tue, Sep 5, 2017 at 6:32 AM, Amit Saha wrote: > Digging up this thread. > This thread was just shy of a year old. It would have been better to start another thread and just reference this one with a link. I guess you are suggesting, that a "client" program (which may

  1   2   3   4   >