[grpc-io] cause=io.netty.handler.codec.http2.Http2Exception: Header size exceeded max allowed size (10240)

Hi I'm seeing the above error on one system that is much slower. On other system the exact same setup works fine. This is on a ubuntu system using 1.2 grpc .. the client see that error going to server running in docker. Java 1.8 The scenario is exactly the same on both machines running through

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

For streaming api have there been issues reported where the is no activity that load balancers would close connections? For Node there is this being reported https://jira.hyperledger.org/browse/FAB-2787 However when I read the Java spec http://www.grpc.io/grpc-java/javadoc/io/grpc/ManagedChanne

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

If not in idle mode can or does grpc implement some sort of keep alive ? -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To pos

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

On Tuesday, May 30, 2017 at 7:18:39 PM UTC-4, cr2...@gmail.com wrote: > > For streaming api have there been issues reported where the is no activity > that load balancers would close connections? > For Node there is this being reported > https://jira.hyperledger.org/browse/FAB-2787 > However wh

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

Currently Node client is looking to fix this doing a heartbeat at the application level. Sending NOP messages This seem like something grpc/http2 should handle. Load balancers are very common. Don't this is off the bat a good way to fix this if it is even an issue for Java -- You received t

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

Thanks that's really great information. How about Java ? Does Java do this too ? On Tuesday, May 30, 2017 at 8:01:37 PM UTC-4, Michael Lumish wrote: > > For the Node client, I think you can enable keepalive HTTP2 pings using > the channel argument "grpc.keepalive_time_ms" as defined at > http

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

I Just noticed that NettyChannelBuilder has a keep alive option. On Tuesday, May 30, 2017 at 8:21:32 PM UTC-4, cr2...@gmail.com wrote: > > Thanks that's really great information. How about Java ? Does Java do > this too ? > > On Tuesday, May 30, 2017 at 8:01:37 PM UTC-4, Michael Lumish wrote: >

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

Some education please on the NettyChannelBuilder vs ManagedChannelBuilder. Code I inherited used ManagedChannelBuilder for grpc (non-TLS) and NettyChannelBuilder for grpcs (TLS). So NettyChannelBuilder is a subclass of ManagedChannelBuilder with more options. Is there any reason to not just

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

Hi I set on a grpc stream with NettyChannel options: keepAliveTime"(60L, TimeUnit.SECONDS}); keepAliveTimeout{8L, TimeUnit.SECONDS}); At times in the code I've added sleep for 15 min. I see on Wireshark the keep alives. But after a time I see : ---

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

Thanks makes sense. I was setting this to 1 sec at one time :) ... not production but just *playing* around and I think it was working without a hitch. However I think they upgraded the server grpc and now im getting this. If this is all that's going on no worries then. Like I said oddly wi

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

Seems to me that there should be an autoback off. Server warning don't call back again for 4 min . Well behaved clients follow that, bad ones get disconnected. On Monday, June 5, 2017 at 7:17:30 PM UTC-4, Eric Anderson wrote: > > In 1.3 we started allowing clients to be more aggressive. From

[grpc-io] Java client streaming api questions

Hi Are the Java steaming APIs thread safe ? If I have a StreamingObserver.onNext() with potentially multiple threads calling that then on the StreamObserver's implemented interface onNext method how can associate the response back to a specific thread's call to the StreamingObserver.onNext()

[grpc-io] Re: Java client streaming api questions

Hi Thanks for the reply- I was under the initial assumption that separate streaming stubs would create separate connections .. but the connection is on the managed channel so at the moment I've moved to just creating one per thread call. On Monday, June 19, 2017 at 2:44:39 PM UTC-4, spenc...@g

[grpc-io] [Java] gRPC failure Connection reset by peer with inactivity.

Hi, I have code that's using the futureStub and using NettyChannelBuilder with no other properties set other than usePlaintext(true); I have users that are claiming everything is working fine except if there's no activity on that connection for about 20 minutes. Then they see: gRPC failure=Sta

[grpc-io] Re: [Java] gRPC failure Connection reset by peer with inactivity.

Also any advise on good practices to make connections appear more resilient to the layers up the stack? On Friday, August 4, 2017 at 10:44:54 AM UTC-4, cr2...@gmail.com wrote: > > Hi, > I have code that's using the futureStub and using NettyChannelBuilder with > no other properties set other th

[grpc-io] Re: [Java] gRPC failure Connection reset by peer with inactivity.

Thanks All ! I finally got some more details and they were NOT running with the keep alive on. And yes, was through some proxy. The keep alive did seem to fix their issues. Thanks for the other answers. On Friday, August 4, 2017 at 10:44:54 AM UTC-4, cr2...@gmail.com wrote: > > Hi, > I ha

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

Hi 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 with requests. I honestly don't know the details of this but j

[grpc-io] grpc Java client Outbound messages size limitations ?

Hi I know of maxInboundMessageSize for incoming messages to a client Are there any controls/restrictions on outbound ? I also know the server can also restrict on how much it will receive (it's inbound) but not really interested in that, just client side configurations/restrictions. Thanks

Re: [grpc-io] Re: grpc Java client Outbound messages size limitations ?

Nothing -- I don't ever try to set the bar that high ;) I seen a Node implementation was setting something on outbound and was worried I was missing something on the Java. Making sure there was no limit for outbound which just fine for me. :) On Wednesday, November 8, 2017 at 5:09:10 PM UTC-5,

[grpc-io] grpc java mutual auth BAD certificate

Hi Seeing this error though it seems the all the certificates do check out ok. grpc java version 1.10.0 javax.net.ssl.SSLHandshakeException : error:1412:SSL routines:OPENSSL_internal:SSLV3_ALERT_BAD_CERTIFICATE Server side auth only works just f

[grpc-io] Re: grpc java mutual auth BAD certificate

Not tried that yet but I removed the keyManger setting and got the very same error. So I'm really now thinking it's nothing actually wrong with the client keys/certs being set there. On Thursday, March 1, 2018 at 2:16:14 PM UTC-5, Carl Mastrangelo wrote: > > Can you try with some of the defaul

[grpc-io] Re: grpc java mutual auth BAD certificate

Does this just wrapper the local native oppenssl implementation ? On Thursday, March 1, 2018 at 2:16:14 PM UTC-5, Carl Mastrangelo wrote: > > Can you try with some of the default certs provided? We use > https://github.com/grpc/grpc-java/tree/master/testing/src/main/resources/certs > > for o

[grpc-io] Re: grpc java mutual auth BAD certificate

I captured our generated cert and the private key in files .. tlsCertPem tlsKeyPem Then did a `openssl s_client -connect localhost:7050 -cert tlsCertPem -key tlsKeyPem -debug` I got what was a telnet like session .. typed a few lines hit enter : and .. ``` orderer.example.com | 2018-03

[grpc-io] Re: grpc java mutual auth BAD certificate

This has been reproduced on Fedora 27 with IBM Jdk / Ubuntu OpenJdk and Mac not sure of what JDK. On Wednesday, February 28, 2018 at 5:47:41 PM UTC-5, cr2...@gmail.com wrote: > > Hi > Seeing this error though it seems the all the certificates do check out ok. > > grpc java version 1.10.0 > >

[grpc-io] Re: grpc java mutual auth BAD certificate

It's possible to give multiple client certificates. Is there some *selection* criteria when connecting to a specific server that determines which *if any* client certs are acceptable ? Will it simpie try all ? (not done much with mutual auth :) On Wednesday, February 28, 2018 at 5:47:41 PM U

[grpc-io] Re: grpc java mutual auth BAD certificate

Hi I see the certificate in the builder. Have not found a reference to private key .. should I? Some guidance where to look ? >>> https://pasteboard.co/Ha2YMA2.jpg On Wednesday, February 28, 2018 at 5:47:41 PM UTC-5, cr2...@gmail.com wrote: > > Hi > Seeing this error though it seems the all the c

[grpc-io] Re: grpc java mutual auth BAD certificate

I think we made some progress. We've got a case where it worked. There were several issue at play making it difficult to nail down and leading to false theories.. It's a bit preliminary but one issue with a particular JDK not *seeming* to work at all, we think. The other is the client certif

[grpc-io] Java grpc connection state

Hi - As a client is there any means of knowing the state of the connection? If I have several endpoints that could service a request is there anything look at the ManagedChannel that would indicate to choose one over the other? -- You received this message because you are subscribed to the Go

[grpc-io] Re: Java grpc connection state

Thanks .. So when I bring down the remote server Current state goes from READY to IDLE . the channel stays in shutdown terminated both to false. It seems to stay that way. At what point would it ever transition out of READY? I tried bringing the remote endpoint back up and that instance of

[grpc-io] Re: Java grpc connection state

I should have pointed out that when queried the state I was using .getState(true); Parameters: requestConnection - if true, the channel will try to make a connection if it is currently IDLE On Saturday, March 3, 2018 at 1:33:30 PM UTC-5, cr2...@gmail.com wrote: > > Hi - > As a client is ther

Re: [grpc-io] Re: Java grpc connection state

Thanks for the responses. I basically figured most of that state table just by playing some with it :) The true vs false on getState was still a mystery. As you indicate it never did anything for me. I think if it was working it would be beneficial. What I'm trying to achieve was prioriti

[grpc-io] grpc Thread pools question

Hi - Can an application override the managment of the thread/pools that grpc uses ? API ? any examples ? Thanks ! -- 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] Re: grpc Thread pools question

Should have added I'm only interested on the client side .. and this Java :) On Thursday, October 4, 2018 at 11:03:02 AM UTC-4, cr2...@gmail.com wrote: > > Hi - > Can an application override the managment of the thread/pools that grpc > uses ? API ? any examples ? > Thanks ! > -- You receive

[grpc-io] Re: grpc Thread pools question

Thanks. On Thursday, October 4, 2018 at 4:25:22 PM UTC-4, Carl Mastrangelo wrote: > > yes, you can call ManagedChannelBuilder.executor() and > ServerBuilder.executor(). I don't have any examples off hand, but we > personally prefer using ForkJoinPool as our executor. > > On Thursday, October 4,

[grpc-io] Java grpc FutureStub threads question

If as a library you're executing grpc future calls on behave on an application is there an issue just using the grpc callback threads? Would there be any need to *transfer* this back to an application provided thread to return the grpc thread back to it's pool? As a library there's really no c

[grpc-io] Re: Java grpc FutureStub threads question

Thanks Carl for the quick response. I think this is what I expected but wanted to make sure. The main take away for now for me is that if an application *hangs* on the callback threads for sometime it won't cause any other grpc requests to block. On Thursday, February 21, 2019 at 8:27:31 PM UT