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

2017-04-20 Thread cr22rc
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] Re: [Java] gRPC failure Connection reset by peer with inactivity.

2017-08-04 Thread cr22rc
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

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

2017-08-04 Thread cr22rc
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

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

2017-06-19 Thread cr22rc
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,

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

2017-05-30 Thread cr22rc
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

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

2017-05-30 Thread cr22rc
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

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

2017-05-30 Thread cr22rc
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 >

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

2017-05-30 Thread cr22rc
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:

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

2017-05-30 Thread cr22rc
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

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

2017-05-30 Thread cr22rc
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

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

2017-06-05 Thread cr22rc
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

2017-06-05 Thread cr22rc
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

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

2017-06-05 Thread cr22rc
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 get server TLS certificate from a StreamObserver connection.

2017-09-05 Thread cr22rc
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

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

2017-11-08 Thread cr22rc
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 ?

2017-11-08 Thread cr22rc
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

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

2018-03-06 Thread cr22rc
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

[grpc-io] grpc java mutual auth BAD certificate

2018-02-28 Thread cr22rc
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

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

2018-03-01 Thread cr22rc
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

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

2018-03-01 Thread cr22rc
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

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

2018-03-03 Thread cr22rc
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

[grpc-io] Java grpc connection state

2018-03-03 Thread cr22rc
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

[grpc-io] Re: Java grpc connection state

2018-03-05 Thread cr22rc
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

[grpc-io] Re: Java grpc connection state

2018-03-05 Thread cr22rc
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

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

2018-03-01 Thread cr22rc
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 |

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

2018-03-01 Thread cr22rc
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

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

2018-03-01 Thread cr22rc
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

2018-03-02 Thread cr22rc
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

[grpc-io] Re: grpc Thread pools question

2018-10-08 Thread cr22rc
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

[grpc-io] Re: grpc Thread pools question

2018-10-04 Thread cr22rc
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

[grpc-io] grpc Thread pools question

2018-10-04 Thread cr22rc
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