Re: [grpc-io] Re: Does gRPC use only http2? tcpdump from a particular client does not show it as http2

[prammadevi]

Thanks.

On Friday, November 30, 2018 at 6:17:56 AM UTC+5:30, Srini Polavarapu wrote:
>
>
>> What does grpc rely on to for http2 capability? (any tool in os 
>> environment or http2 capability is inbuilt in grpc?)
>>
>
> gRPC Python has a built-in HTTP/2 stack. 
>
>
> On Thursday, November 29, 2018 at 10:13:27 AM UTC-8, Josh Humphries wrote:
>>
>> The main gRPC libraries *only* use HTTP/2. As you saw, they negotiate 
>> the same protocol during NPN step of TLS handshake: "h2". It is more likely 
>> that whatever analysis tool you used in the first case did not recognize 
>> "h2" as the HTTP/2 protocol, so treated it as an unknown application 
>> protocol.
>>
>> 
>> *Josh Humphries*
>> jh...@bluegosling.com
>>
>>
>> On Thu, Nov 29, 2018 at 1:42 AM  wrote:
>>
>>> Thanks for the prompt response.
>>> We use Python grpcio 1.0.0. 
>>> No as i mentioned, for now version will not be updated as Network device 
>>> i am talking about is already deployed in customer networks.
>>> We have to make our application work with this for now.
>>>
>>> My question is more towards, 
>>> What does grpc rely on to for http2 capability? (any tool in os 
>>> environment or http2 capability is inbuilt in grpc?)
>>> Why same version in another Ubuntu VM used http2, where as this specific 
>>> env, it did not use http2?
>>>
>>> -- 
>>> 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+u...@googlegroups.com.
>>> To post to this group, send email to grp...@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/grpc-io.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/grpc-io/ff3c3be4-e3e0-4f3d-af4e-73595f2018e0%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/99f9577b-5deb-4eb7-90cf-d69524f8be7b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Does gRPC use only http2? tcpdump from a particular client does not show it as http2

[prammadevi]

Thanks for writing.
Same tool i am using for capturing and viewing 2 dumps, 1 dump it shows 
http2 where as this dump it shows application protocol.
Looking at other replies and going thru other documents, i hope grpc cannot 
work without http2.

But my issue is at least half of the time, after Server Hello, client 
closes the connection sending TCP FIN. 
For that i am trying to understand the root cause for the same. 

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/6c907e6a-6feb-4adc-842a-54d822d8b47e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Greetings from gRPC!

['April Kyle Nassi' via grpc.io]

Hi everyone! Due to the holidays and other commitments, it's been a while
since we had a gRPC community call and I wanted to quickly update you on
some things in the works.


   - If you're in the SF Bay Area, we'd love to have you join us next week
   on the 5th for a Meetup in SF! Ryan Michela from Salesforce will be
   presenting on gRPC Extensibility
   .
   - Are you headed to KubeCon in Seattle? Let us know
   ! We'd love to meet
   you.
   - It's not to early to be thinking about the *next* KubeCon! The CFP for
   KubeCon EU
   

   is now open and accepting submissions until January 18.


We've got some other great things in the works, so stay tuned! We'll see
you either next week in SF or virtually on our community call
; and then the week after in Seattle.

Talk soon,
April





*April Kyle Nassi, Program Manager*

Google, Inc. | Open Source Strategy | Developer Relations

345 Spear Street, San Francisco, CA 94105


ana...@google.com | @thisisnotapril 

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAAgWDxLTT7dNh5phHvCwrmRwMww3pGAFa-mHh61uBvEL2JUBYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Repeated blog article rss feed

[alan0098]

Thanks for your suggestion, issued 
.

On Friday, November 30, 2018 at 3:08:05 AM UTC+8, Carl Mastrangelo wrote:
>
> I believe the RSS feed is from github.io, so you may need to file a bug 
> there.  I have emailed them in the past (their email is on the GitHub 
> contact page), and they have been helpful to me in the past. 
>
> On Tuesday, November 27, 2018 at 5:46:17 PM UTC-8, alan...@gmail.com 
> wrote:
>>
>> Hi there,
>>
>> I subscribe the blog rss feed, there is a strange phenomenon since two 
>> monthg ago, that is, an article rss feed repeats in random period, its 
>> title is "In a previous article , we explored how HTTP/2 dramatically 
>> increases network efficiency and enables real-time communic...", and links 
>> to https://grpc.io//2018/11/27/2018-08-20-grpc-on-http2.html
>>
>> Anyone can fix that? 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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/f970ae36-6bf1-4aea-a8f6-6b48590407d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] libgrpc++: Enabling debug trace on Android

['Michael Lumish' via grpc.io]

Have you tried "GRPC_VERBOSITY=DEBUG"? Our environment variables are
unfortunately case-sensitive with varying casing conventions

On Thu, Nov 29, 2018 at 4:18 PM David Collins  wrote:

> Hi all,
>
> I have cross-compiled version 1.17.0 of the libgrpc++ library for the
> Android platform. When I link against this library in a test program for
> Android, the program runs successfully, but I can't view the extra logs and
> traces to debug.
>
> Specifically, I have tried
>
> GRPC_VERBOSITY=debug GRPC_TRACE=api ./grpc-test
>
> as well as variations on the above - e.g. using 'info' instead of 'debug'
> for the verbosity level. The program runs, but no trace info is displayed.
>
> I am logging in to the Android console via `adb shell` to run the program.
> I have tried this on both a 32-bit ARM architecture (running Android 4.4)
> and an x86 emulator (need to check the Android version) - without success.
> When I compile the same program for my Linux desktop, I can view the debug
> trace without problem.
>
> The libgrpc++ library is being compiled with debugging enabled, and I can
> actually debug the program using gdb + gdbserver. In some cases I would
> just prefer to debug using the 'trace' features of the library rather than
> gdb however.
>
> My ultimate problem is that the library is failing to communicate with
> Google's TTS API. I am using `GoogleDefaultCredentials()` to retrieve
> credentials (and the GOOGLE_APPLICATION_CREDENTIALS environment variable is
> set correctly). When I try to invoke any method on the TextToSpeech::Stub,
> the request times out with the channel in state
> GRPC_CHANNEL_TRANSIENT_FAILURE. (I have used `set_deadline()` and
> `set_wait_for_ready(true)`).
>
> The same program works as expected on Debian Linux. If I could view the
> trace on Android, it might help me to diagnose why it's failing there.
>
> Can anyone think of a reason why the trace might not be activated on
> Android?
>
> Incidentally, I have run a separate gRPC program on my Android device
> without problem - in this instance communicating with an insecure test
> server (using `InsecureChannelCredentials()`). Perhaps it's a
> SSL/TLS-related issue.
>
> --
> 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 post to this group, send email to grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/3599dfc6-bc6a-470e-a339-364117a95fae%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAPK2-4cGGW2ptUnx0d2a%3DaW-P39MhAkhn1Sg%2BKxMWm3AKx_WSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [grpc-io] Re: Does gRPC use only http2? tcpdump from a particular client does not show it as http2

['Srini Polavarapu' via grpc.io]

>
>
> What does grpc rely on to for http2 capability? (any tool in os 
> environment or http2 capability is inbuilt in grpc?)
>

gRPC Python has a built-in HTTP/2 stack. 


On Thursday, November 29, 2018 at 10:13:27 AM UTC-8, Josh Humphries wrote:
>
> The main gRPC libraries *only* use HTTP/2. As you saw, they negotiate the 
> same protocol during NPN step of TLS handshake: "h2". It is more likely 
> that whatever analysis tool you used in the first case did not recognize 
> "h2" as the HTTP/2 protocol, so treated it as an unknown application 
> protocol.
>
> 
> *Josh Humphries*
> jh...@bluegosling.com 
>
>
> On Thu, Nov 29, 2018 at 1:42 AM > wrote:
>
>> Thanks for the prompt response.
>> We use Python grpcio 1.0.0. 
>> No as i mentioned, for now version will not be updated as Network device 
>> i am talking about is already deployed in customer networks.
>> We have to make our application work with this for now.
>>
>> My question is more towards, 
>> What does grpc rely on to for http2 capability? (any tool in os 
>> environment or http2 capability is inbuilt in grpc?)
>> Why same version in another Ubuntu VM used http2, where as this specific 
>> env, it did not use http2?
>>
>> -- 
>> 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+u...@googlegroups.com .
>> To post to this group, send email to grp...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/grpc-io.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/grpc-io/ff3c3be4-e3e0-4f3d-af4e-73595f2018e0%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/7eb04fb9-d29c-41a7-8c09-f7ac4b5504e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] libgrpc++: Enabling debug trace on Android

[David Collins]

Hi all,

I have cross-compiled version 1.17.0 of the libgrpc++ library for the 
Android platform. When I link against this library in a test program for 
Android, the program runs successfully, but I can't view the extra logs and 
traces to debug.

Specifically, I have tried

GRPC_VERBOSITY=debug GRPC_TRACE=api ./grpc-test

as well as variations on the above - e.g. using 'info' instead of 'debug' 
for the verbosity level. The program runs, but no trace info is displayed.

I am logging in to the Android console via `adb shell` to run the program. 
I have tried this on both a 32-bit ARM architecture (running Android 4.4) 
and an x86 emulator (need to check the Android version) - without success. 
When I compile the same program for my Linux desktop, I can view the debug 
trace without problem.

The libgrpc++ library is being compiled with debugging enabled, and I can 
actually debug the program using gdb + gdbserver. In some cases I would 
just prefer to debug using the 'trace' features of the library rather than 
gdb however.

My ultimate problem is that the library is failing to communicate with 
Google's TTS API. I am using `GoogleDefaultCredentials()` to retrieve 
credentials (and the GOOGLE_APPLICATION_CREDENTIALS environment variable is 
set correctly). When I try to invoke any method on the TextToSpeech::Stub, 
the request times out with the channel in state 
GRPC_CHANNEL_TRANSIENT_FAILURE. (I have used `set_deadline()` and 
`set_wait_for_ready(true)`).

The same program works as expected on Debian Linux. If I could view the 
trace on Android, it might help me to diagnose why it's failing there.

Can anyone think of a reason why the trace might not be activated on 
Android?

Incidentally, I have run a separate gRPC program on my Android device 
without problem - in this instance communicating with an insecure test 
server (using `InsecureChannelCredentials()`). Perhaps it's a 
SSL/TLS-related issue.

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/3599dfc6-bc6a-470e-a339-364117a95fae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Measuring gRPC-Java Unary Client Requests Latency From Interceptor

['Carl Mastrangelo' via grpc.io]

System.currentTimeMillis() is not ideal for measuring elapsed time.  It's meant 
for measure the current time.  Instead, try doing:


long startNanos = System.nanoTime();

// ... Do the RPC

long stopNanos = System.nanoTime();

tick("GrpcClient.Get", TimeUnit.NANOSECONDS.toMillis(stopNanos - startNanos));


As for the discrepancy, are you sure you don't have any exceptions being 
thrown?  If the call failed the time would not be recorded.  This is important 
for deadline exceeded calls, because they would make the average latency go way 
up.




On Thursday, November 29, 2018 at 1:24:20 PM UTC-8, Yee-Ning Cheng wrote:
>
> I also have a metric that surrounds the actual blocking call (I am using the 
> blocking stub in this case).
>
>
> Long time = System.currentTimeMillis();
> Userprofile.ReadResponse resp = blockingStub
> .withDeadlineAfter(timeout, TimeUnit.MILLISECONDS)
> .get(req.build());
> tick("GrpcClient.Get", System.currentTimeMillis() - time);
>
>
>
> The issue is that this metric (the one surrounding the blocking call) is 
> reporting a much lower latency (~100ms vs ~400ms).  Why is there such a 
> discrepancy?  And which one is correct?
>
>
> I will look into the ClientStreamTracer to see what's there as well. Thanks!
>
>
> On Thursday, November 29, 2018 at 3:57:31 PM UTC-5, Carl Mastrangelo wrote:
>>
>> That is one way.  For more precise (but about as accurate) numbers, 
>> consider using a ClientStreamTracer, which you can set on the 
>> ManagedChannelBuilder.  That has more fine-grained events about an RPC. 
>>
>> On Wednesday, November 28, 2018 at 1:55:12 PM UTC-8, Yee-Ning Cheng wrote:
>>>
>>> I am trying to measure gRPC unary requests from a client.
>>>
>>> I have implemented an interceptor very similar to
>>>
>>>
>>> https://github.com/grpc-ecosystem/java-grpc-prometheus/blob/master/src/main/java/me/dinowernli/grpc/prometheus/MonitoringClientCallListener.java
>>>
>>> I also have a metric surrounding the client call and this time is much 
>>> lower than the time measured from the interceptor.
>>>
>>> Is the above interceptor implementation the correct way to measure each 
>>> unary request from the client?
>>>
>>> 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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/1edc0fa9-05a1-4e4f-84cd-e07e59769a0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: java LB round-robin has 30 minutes blank window before re-resolve

[eleanore . jin]

Hi Carl, 

Thanks for the reply:

1. how do I kill the instances: docker stop the container of the gRPC 
server.  is this what you meant by 'pull the plug?'
2. when you say: DNS is pull based, so we implemented as a timer based 
refresh, but it isn't desirable, so you mean the DNS refresh will be called 
periodically? If so, what is the configuration for the period? is it hard 
coded in the code (can you please point to me the class) or it is 
configurable (if so, please also point to me how I can configure it)?

For my project, it is just I extends io.grpc.NameResolver and overwrite 
getServiceAuthority, start(Listener listener), refresh and shutdown 
methods. 


Thanks a lot!

On Thursday, November 29, 2018 at 1:14:37 PM UTC-8, Carl Mastrangelo wrote:
>
> Responses inline
>
> On Wednesday, November 28, 2018 at 2:23:13 PM UTC-8, eleano...@gmail.com 
> wrote:
>>
>> Here is the test case:
>>
>> I have implemented my custom NameResolver, and using RoundRobinLoadBalancer 
>> in managedChannelBuilder. 
>>
>> 1. initially has 4 instances running (serverA, serverB, serverC, serverD)
>>
>> 2. then kill 2 instances (serverC, serverD), then serverA and serverB 
>> continues serving the request
>>
>
> Do you mean gracefully shutdown, or just pull the plug?  gRPC has no way 
> of knowing the latter case, which means you need to turn on keep-alives in 
> the channel.
>  
>
>>
>> 3. then create 2 more instances (serverE, serverF), only serverA and 
>> serverB continues serving the request, since the NameResolver::refresh is 
>> only triggered due to connection failures or GOAWAY signal.
>>
>
> Name resolvers are meant to be push based.   It is expected that some 
> other service will notify your name resolver when new servers enter the 
> pool.   DNS is pull based, so we implemented as a timer based refresh, but 
> it isn't desirable.  If in your custom resolver you pull, then you'll have 
> to use a timer like DNS does. 
>  
>
>>
>> 4. then kill serverA and serverB, there is 30 minutes blank window, that 
>> gRPC seems not doing anything, then after 30 minutes NameResolver::refresh 
>> is triggered and the messages are served by serverE and serverF. (seems no 
>> messaging loss).
>>
>> Can someone please suggest why there is a 30 minutes blank window, and is 
>> there anyway we can configure it to be shorter?
>>
>> Thanks a lot!
>>
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/cea7815a-f269-473d-afe0-d50b6e363faf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Measuring gRPC-Java Unary Client Requests Latency From Interceptor

[Yee-Ning Cheng]

I also have a metric that surrounds the actual blocking call (I am using the 
blocking stub in this case).


Long time = System.currentTimeMillis();
Userprofile.ReadResponse resp = blockingStub
.withDeadlineAfter(timeout, TimeUnit.MILLISECONDS)
.get(req.build());
tick("GrpcClient.Get", System.currentTimeMillis() - time);



The issue is that this metric (the one surrounding the blocking call) is 
reporting a much lower latency (~100ms vs ~400ms).  Why is there such a 
discrepancy?  And which one is correct?


I will look into the ClientStreamTracer to see what's there as well. Thanks!


On Thursday, November 29, 2018 at 3:57:31 PM UTC-5, Carl Mastrangelo wrote:
>
> That is one way.  For more precise (but about as accurate) numbers, 
> consider using a ClientStreamTracer, which you can set on the 
> ManagedChannelBuilder.  That has more fine-grained events about an RPC. 
>
> On Wednesday, November 28, 2018 at 1:55:12 PM UTC-8, Yee-Ning Cheng wrote:
>>
>> I am trying to measure gRPC unary requests from a client.
>>
>> I have implemented an interceptor very similar to
>>
>>
>> https://github.com/grpc-ecosystem/java-grpc-prometheus/blob/master/src/main/java/me/dinowernli/grpc/prometheus/MonitoringClientCallListener.java
>>
>> I also have a metric surrounding the client call and this time is much 
>> lower than the time measured from the interceptor.
>>
>> Is the above interceptor implementation the correct way to measure each 
>> unary request from the client?
>>
>> 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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/a74bd564-5fa4-4dc9-9f1c-8b238dbdcf8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Fail over takes too long because of TCP retransmission

['Carl Mastrangelo' via grpc.io]

The main way we solve this is by enabling client side keep-alives, which 
IIRC run once every 45 second if there are no active RPCs.  These are 
implemented in gRPC as HTTP/2 Ping frames.   I can't say I know where this 
is for Go, but in Java this is an actively used feature.

On Monday, November 26, 2018 at 11:26:39 AM UTC-8, John Shahid wrote:
>
>
> We ended up adding the following to `Dial': 
>
> grpc.WithKeepaliveParams(keepalive.ClientParameters{ 
> Time: 10 * time.Second, 
> }) 
>
> This required bumping grpc to a commit that included the fix in 
> https://github.com/grpc/grpc-go/pull/2307 which sets the 
> TCP_USER_TIMEOUT socket option on Linux.  On a side note, this issue 
> doesn't affect windows clients.  It looks like by default windows 
> retransmissions are much lower than on GNU/Linux. 
>
>
> John Shahid > writes: 
>
> > Hi all, 
> > 
> > We just ran into an interesting issue.  We are using grpc-go for both 
> > the client and server implementation.  There are two instance of the 
> > server deployed for HA.  Clients use dns name lookup and usually are 
> > split evenly between the two servers. 
> > 
> > One of the servers had a network issue and wasn't reachable (we were 
> > able to simulate this situation by adding an iptables rule to drop 
> > packets destined to one of the two servers).  The DNS server immediately 
> > detect that one of the servers isn't reachable and removes it from the 
> > pool.  What we observed is that clients connected to that instance will 
> > keep getting "context deadline exceeded" errors for about 15 minutes. 
> > The tcpdump show multiple retransmission attempts.  The client will 
> > eventually (after ~15 minutes) reconnect to the healthy instance. 
> > 
> > Is there a way to speed up the fail over without changing the number of 
> > TCP retransmissions in `/proc/sys/net/ipv4/tcp_retries2' ? 
> > 
> > Thanks, 
> > 
> > JS 
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/1d2b7860-b429-4019-8798-229cd7a36a27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Binlog as a gRPC service?

['Carl Mastrangelo' via grpc.io]

I'm not sure that there is a service in mind, but it would need some sort 
of special treatment if it did exist. (i.e. do binlog gRPCs themselves get 
logged?)

Also, what happens if the log service hangs, gets backed up, or is 
unreachable?  

On Wednesday, November 28, 2018 at 5:22:43 AM UTC-8, to...@spotify.com 
wrote:
>
>
> Is there a plan to support on-demand streaming of binary logs by providing 
> it as a gRPC service or maybe a reason not to support it?
>
> With this example service definition:   
>
> service BinaryLogz {
>   rpc GetBinaryLogs(BinaryLogRequest) returns (stream BinaryLogResponse);
> }
>
> we wouldn't require any additional logging infrastructure for the simple 
> case of taping into a single instance request/response flow.  
>
> As simple CLI could be use to stream the response to stdout or dump it to 
> a file to be replayed/inspected later:   
>
> gdump -d '{"log_filter": 
> "Foo/*,Foo/Bar{m:256}"}' grpc.binarylog.v1alpha.BinaryLogz/GetBinaryLogs -o 
> binlog.rio
>
> I understand that this might be complicated to implement for all languages 
> and might not make sense to have in core, but I wanted to to float the 
> idea.  
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/d5c7b043-1669-4506-8407-1c1fe3e0d561%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: java LB round-robin has 30 minutes blank window before re-resolve

['Carl Mastrangelo' via grpc.io]

Responses inline

On Wednesday, November 28, 2018 at 2:23:13 PM UTC-8, eleano...@gmail.com 
wrote:
>
> Here is the test case:
>
> I have implemented my custom NameResolver, and using RoundRobinLoadBalancer 
> in managedChannelBuilder. 
>
> 1. initially has 4 instances running (serverA, serverB, serverC, serverD)
>
> 2. then kill 2 instances (serverC, serverD), then serverA and serverB 
> continues serving the request
>

Do you mean gracefully shutdown, or just pull the plug?  gRPC has no way of 
knowing the latter case, which means you need to turn on keep-alives in the 
channel.
 

>
> 3. then create 2 more instances (serverE, serverF), only serverA and 
> serverB continues serving the request, since the NameResolver::refresh is 
> only triggered due to connection failures or GOAWAY signal.
>

Name resolvers are meant to be push based.   It is expected that some other 
service will notify your name resolver when new servers enter the pool.  
 DNS is pull based, so we implemented as a timer based refresh, but it 
isn't desirable.  If in your custom resolver you pull, then you'll have to 
use a timer like DNS does. 
 

>
> 4. then kill serverA and serverB, there is 30 minutes blank window, that 
> gRPC seems not doing anything, then after 30 minutes NameResolver::refresh 
> is triggered and the messages are served by serverE and serverF. (seems no 
> messaging loss).
>
> Can someone please suggest why there is a 30 minutes blank window, and is 
> there anyway we can configure it to be shorter?
>
> Thanks a lot!
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/ce805b16-2629-4331-96f2-97150ac50a66%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: gRPC over the internet at scale

['Carl Mastrangelo' via grpc.io]

I can't speak for most middle boxes, but at least nginx does have pretty 
good http2 support.   I believe that is pretty common.

The main issue I see with middle boxes is not supporting TLS ALPN (which 
HTTP/2 depends on).   This is common in packet inspecting firewalls, which 
lag in functionality.

That said, Google is gainfully using gRPC in some flagship Android 
applications, so it definitely has some experience in exotic environments.



On Monday, November 26, 2018 at 10:25:01 AM UTC-8, cka...@slack-corp.com 
wrote:
>
> I'm evaluating use of gRPC between mobile clients and servers, and was 
> curious if anyone has experience using gRPC in a production setting, over 
> the internet, at scale. I'm generally curious about the use cases, learning 
> and outcomes of switching to gRPC. A particular area of concern we have is 
> the reliance on HTTP2 and lack of automated fallback to HTTP1. Even if we 
> get all our infrastructure to support terminating HTTP2-gRPC, we are 
> concerned that network middle boxes may interfere with, or block, gRPC 
> connections.
>
> Thanks,
> Cy
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/be58d750-2a40-4835-b497-81efd8a67a4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [java] - gRPC ThreadPoolExecutor and bounded queue

['Carl Mastrangelo' via grpc.io]

I would modify the counters before calling super (in case they throw an 
exception).  Also, I (personally), would fail the RPCs early rather than 
doing resize of the pool.   You can invoke call.close(Status.CANCELED), and 
then return a noop listener, instead of invoked methods on next.

On Thursday, November 29, 2018 at 12:56:00 PM UTC-8, 
in...@olivierboucher.com wrote:
>
> Thank you Carl.
>
> Is something like this what you meant? I striped out the resizing logic... 
> activeCalls is an AtomicInteger
>
> @Override
> public  ServerCall.Listener 
> interceptCall(ServerCall call, Metadata headers, 
> ServerCallHandler next) {
> resizePool(activeCalls.incrementAndGet());
> ServerCall.Listener delegate = next.startCall(call, headers);
> return new 
> ForwardingServerCallListener.SimpleForwardingServerCallListener(delegate)
>  
> {
> @Override
> public void onCancel() {
> super.onCancel();
> activeCalls.decrementAndGet();
> }
>
> @Override
> public void onComplete() {
> super.onComplete();
> activeCalls.decrementAndGet();
> }
> };
> }
>
>
>
>
>
> On Thursday, 29 November 2018 13:57:36 UTC-5, Carl Mastrangelo wrote:
>>
>> You *really* don't want to limit the queue size.  The queue is not per 
>> RPC, but per RPC callback event.   If the enqueue'd callback (like headers 
>> received, data received, cancellation, etc.) gets dropped, the RPC will be 
>> in a zombie state and never able to finish or die.  Additionally, if you 
>> block on attempting to add callbacks (instead of just failing them), you 
>> run the risk of deadlocking, because the net thread will be blocked on the 
>> application thread.
>>
>> The BlockingQueue in the executor is not a good fit for async callbacks.  
>>  It would be much better to install an Interceptor that keeps track of the 
>> number of active calls, and simply fails RPCs (instead of callbacks) if the 
>> number gets too high.   
>>
>> On Thursday, November 29, 2018 at 8:43:04 AM UTC-8, 
>> in...@olivierboucher.com wrote:
>>>
>>>
>>> Hi everyone,
>>>
>>> Our gRPC server runs on a ThreadPoolExecutor with a corePoolSize of 4 
>>> and a maximumPoolSize of 16. In order to have the pool size increase, we 
>>> provide a BlockingQueue with a bounded size of 20. 
>>>
>>> Sometimes short bursts happen and we're perfectly fine with dropping 
>>> requests at this moment, we provided a custom RejectionExecutionHandler 
>>> that increases a counter we are monitoring. However, this rejection handler 
>>> is not aware of the request itself, it only sees a Runnable.
>>>
>>> My question is: are the requests automatically canceled if they could 
>>> not get queued? Do I need to cancel them manually somehow?
>>>
>>> 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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/63e7bb11-9269-4dba-b66b-b3de763d7e3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Measuring gRPC-Java Unary Client Requests Latency From Interceptor

['Carl Mastrangelo' via grpc.io]

That is one way.  For more precise (but about as accurate) numbers, 
consider using a ClientStreamTracer, which you can set on the 
ManagedChannelBuilder.  That has more fine-grained events about an RPC. 

On Wednesday, November 28, 2018 at 1:55:12 PM UTC-8, Yee-Ning Cheng wrote:
>
> I am trying to measure gRPC unary requests from a client.
>
> I have implemented an interceptor very similar to
>
>
> https://github.com/grpc-ecosystem/java-grpc-prometheus/blob/master/src/main/java/me/dinowernli/grpc/prometheus/MonitoringClientCallListener.java
>
> I also have a metric surrounding the client call and this time is much 
> lower than the time measured from the interceptor.
>
> Is the above interceptor implementation the correct way to measure each 
> unary request from the client?
>
> 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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/6d46c517-f86d-45b7-aa07-494cbf385e7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [java] - gRPC ThreadPoolExecutor and bounded queue

[info]

Thank you Carl.

Is something like this what you meant? I striped out the resizing logic... 
activeCalls is an AtomicInteger

@Override
public  ServerCall.Listener 
interceptCall(ServerCall call, Metadata headers, 
ServerCallHandler next) {
resizePool(activeCalls.incrementAndGet());
ServerCall.Listener delegate = next.startCall(call, headers);
return new 
ForwardingServerCallListener.SimpleForwardingServerCallListener(delegate) 
{
@Override
public void onCancel() {
super.onCancel();
activeCalls.decrementAndGet();
}

@Override
public void onComplete() {
super.onComplete();
activeCalls.decrementAndGet();
}
};
}





On Thursday, 29 November 2018 13:57:36 UTC-5, Carl Mastrangelo wrote:
>
> You *really* don't want to limit the queue size.  The queue is not per 
> RPC, but per RPC callback event.   If the enqueue'd callback (like headers 
> received, data received, cancellation, etc.) gets dropped, the RPC will be 
> in a zombie state and never able to finish or die.  Additionally, if you 
> block on attempting to add callbacks (instead of just failing them), you 
> run the risk of deadlocking, because the net thread will be blocked on the 
> application thread.
>
> The BlockingQueue in the executor is not a good fit for async callbacks.  
>  It would be much better to install an Interceptor that keeps track of the 
> number of active calls, and simply fails RPCs (instead of callbacks) if the 
> number gets too high.   
>
> On Thursday, November 29, 2018 at 8:43:04 AM UTC-8, 
> in...@olivierboucher.com wrote:
>>
>>
>> Hi everyone,
>>
>> Our gRPC server runs on a ThreadPoolExecutor with a corePoolSize of 4 and 
>> a maximumPoolSize of 16. In order to have the pool size increase, we 
>> provide a BlockingQueue with a bounded size of 20. 
>>
>> Sometimes short bursts happen and we're perfectly fine with dropping 
>> requests at this moment, we provided a custom RejectionExecutionHandler 
>> that increases a counter we are monitoring. However, this rejection handler 
>> is not aware of the request itself, it only sees a Runnable.
>>
>> My question is: are the requests automatically canceled if they could not 
>> get queued? Do I need to cancel them manually somehow?
>>
>> 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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/e31d1dc7-4442-44e3-8dcf-fa1d15c603ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Thread configuration for low latency in high throughput scenario

['Carl Mastrangelo' via grpc.io]

+1 To what Robert said.   You have a couple options here:   

* use ForkJoinPool, which scales much more gracefully under load.  
* If your RPC logic is pretty simple, and does not block (like, ever),  
 you can use directExecutor() on the server builder and run RPCs inline.  
This avoids the need for the executor, and pushes all work into the worker 
EventLoopGroup
* Consider using an eventloop and channel type that scale better under 
load.  I recommend EpollServerSocketChannel, and the corresponding event 
loop.

On Tuesday, November 27, 2018 at 11:30:02 AM UTC-8, robert engels wrote:
>
> If you get multiple requests that are external, and all of these take 
> 200ms, you are going to be blocked… if the requests are IO bound, then 4 is 
> too small for the pool, and by increasing the pool size if other requests 
> arrive that are not external they can be handled
>
> On Nov 27, 2018, at 1:19 PM, Hugo Migneron  > wrote:
>
> Hi,
>
> We run a high throughput gRPC server (in Java) with a target latency of 
> sub 15ms. A vast majority of the requests are executed within that 
> timeframe. However, a small percentage of the requests rely on an external 
> service that must be executed inline. It is generally fast (~20ms) but can 
> sometimes be slow (200+ ms). We do timeout these external service requests 
> at 200ms, but we noticed that our event loop blocks when timeouts happen 
> the effect on latency snowballs and we quickly start taking more than 2 
> seconds to process requests. Things remain that way for a few seconds until 
> the latency gets back on track again.
>
> We run on kubernetes and our docker container is provided with about 1.5 
> to 2 CPU. There are many replicas of the same server.
>
> Here's how we start the server : 
>
> ```
>
> LinkedBlockingQueue workerQueue = new LinkedBlockingQueue<>();
> EFThreadFactory factory = new EFThreadFactory(); // Does nothing 
> fancy/special
> ExecutorService executorService = new ThreadPoolExecutor(4, 4, 0L, 
> TimeUnit.MILLISECONDS, workerQueue, threadFactory);
> Server server = NettyServerBuilder.forPort(port)
> .executor(executorService)
> .addService(new OurService())
> .build()
> .start();
>
> ```
>
> Does this configuration make sense given our goals and the situation we're 
> in ? If not, what would be the optimal configuration to avoid blocking the 
> event loop ?
>
> Would increasing `maximumPoolSize` of the executor be of any benefit 
> given the low amount of CPU each server gets ?
>
> If thread configuration / the posted code is not the issue here, any 
> pointers as to what I should look at / understand in order to solve the 
> problem ?
>
> Thank you !
>
>
> -- 
> 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+u...@googlegroups.com .
> To post to this group, send email to grp...@googlegroups.com 
> .
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/grpc-io/db13c95b-db49-4a21-b912-f841a38cc85c%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/99307073-2ac5-4c8e-ba58-e1328eab7ac0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Executing the client's send message in a separate thread?

['Carl Mastrangelo' via grpc.io]

Are you using Netty?  If so, you can set a direct executor (using 
MoreExecutors.directExecutor()).For the outbound path it will involve a 
thread hop (see WriteQueue), but for inbound it will not.   If you respond 
to RPCs directly on the thread that receives them, then there is no thread 
hop at all. 

On Tuesday, November 27, 2018 at 10:20:42 AM UTC-8, ted_g...@yahoo.com 
wrote:
>
>
> When making an async call from a Java client we are seeing that the 
> outgoing call happens on the originating thread.  This takes about 40 
> microseconds on our machine and we'd like the originating thread not to be 
> blocked for that time.  
>
> How do we configure gRPC such that the outgoing call is built and sent out 
> the socket on a worker thread?  We have tried various Executors with no 
> luck.
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/ff94494b-353b-4fd7-b0c0-1199d2da4f86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Repeated blog article rss feed

['Carl Mastrangelo' via grpc.io]

I believe the RSS feed is from github.io, so you may need to file a bug 
there.  I have emailed them in the past (their email is on the GitHub 
contact page), and they have been helpful to me in the past. 

On Tuesday, November 27, 2018 at 5:46:17 PM UTC-8, alan...@gmail.com wrote:
>
> Hi there,
>
> I subscribe the blog rss feed, there is a strange phenomenon since two 
> monthg ago, that is, an article rss feed repeats in random period, its 
> title is "In a previous article , we explored how HTTP/2 dramatically 
> increases network efficiency and enables real-time communic...", and links 
> to https://grpc.io//2018/11/27/2018-08-20-grpc-on-http2.html
>
> Anyone can fix that? 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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/850e6f21-0399-4a79-b675-c2f9cab20e85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: Recommended gRPC URI scheme

['Carl Mastrangelo' via grpc.io]

Hi Jakob!

gRPC has it's own name resolution built into it's own URLs, so it may get 
confusing.  For example, a dns based gRPC service would be 
dns:///localhost:9988 .   Note the actual address info is in the /path/ of 
the URI, rather than the host or authority.  For domain socket based 
connections, its uds:///tmp/file.sock

If you plan on supporting the multiple name resolution schemes gRPC has, 
you would need to embed the full gRPC URL into the the URL you planned on 
using.   Like grpc:///dns:///localhost:9988

As for the name, I would avoid including the "s" at the end.   Several 
plaintext protocols are actually secure (such as in memory, UDS, or via a 
Secure proxy). If you can limit the scope of supported protocols, you 
can probably do something like grpc+plaintext:///   or something along 
those lines, as I have seen that elsewhere.


HTH,
Carl 

On Thursday, November 29, 2018 at 4:47:08 AM UTC-8, Jakob Buchgraber wrote:
>
> Hi,
>
> in our project we want to allow a user to specify a URI to a service 
> endpoint via a flag. We support multiple protocols
> for talking to service endpoints, including gRPC. The current plan is to 
> select the protocol to use based on the scheme
> component of the URI.
>
> Do you provide any guidance as to what name to use for the scheme? I was 
> thinking "grpc" and "grpcs" to be
> reasonable to choices.
>
> Thanks,
> Jakob
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/4843f338-47d2-493f-81f6-c28a9f9f4916%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: [java] - gRPC ThreadPoolExecutor and bounded queue

['Carl Mastrangelo' via grpc.io]

You *really* don't want to limit the queue size.  The queue is not per RPC, 
but per RPC callback event.   If the enqueue'd callback (like headers 
received, data received, cancellation, etc.) gets dropped, the RPC will be 
in a zombie state and never able to finish or die.  Additionally, if you 
block on attempting to add callbacks (instead of just failing them), you 
run the risk of deadlocking, because the net thread will be blocked on the 
application thread.

The BlockingQueue in the executor is not a good fit for async callbacks.  
 It would be much better to install an Interceptor that keeps track of the 
number of active calls, and simply fails RPCs (instead of callbacks) if the 
number gets too high.   

On Thursday, November 29, 2018 at 8:43:04 AM UTC-8, 
in...@olivierboucher.com wrote:
>
>
> Hi everyone,
>
> Our gRPC server runs on a ThreadPoolExecutor with a corePoolSize of 4 and 
> a maximumPoolSize of 16. In order to have the pool size increase, we 
> provide a BlockingQueue with a bounded size of 20. 
>
> Sometimes short bursts happen and we're perfectly fine with dropping 
> requests at this moment, we provided a custom RejectionExecutionHandler 
> that increases a counter we are monitoring. However, this rejection handler 
> is not aware of the request itself, it only sees a Runnable.
>
> My question is: are the requests automatically canceled if they could not 
> get queued? Do I need to cancel them manually somehow?
>
> 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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/9c124d4b-e3da-4927-b552-2a09bae0c6d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Re: Does gRPC use only http2? tcpdump from a particular client does not show it as http2

[Josh Humphries]

The main gRPC libraries *only* use HTTP/2. As you saw, they negotiate the
same protocol during NPN step of TLS handshake: "h2". It is more likely
that whatever analysis tool you used in the first case did not recognize
"h2" as the HTTP/2 protocol, so treated it as an unknown application
protocol.


*Josh Humphries*
jh...@bluegosling.com


On Thu, Nov 29, 2018 at 1:42 AM  wrote:

> Thanks for the prompt response.
> We use Python grpcio 1.0.0.
> No as i mentioned, for now version will not be updated as Network device i
> am talking about is already deployed in customer networks.
> We have to make our application work with this for now.
>
> My question is more towards,
> What does grpc rely on to for http2 capability? (any tool in os
> environment or http2 capability is inbuilt in grpc?)
> Why same version in another Ubuntu VM used http2, where as this specific
> env, it did not use http2?
>
> --
> 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 post to this group, send email to grpc-io@googlegroups.com.
> Visit this group at https://groups.google.com/group/grpc-io.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/grpc-io/ff3c3be4-e3e0-4f3d-af4e-73595f2018e0%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/CAO78j%2B%2B1CtXWeo8qdht3GunEKKLXZD%2BYqo7RmDAv8yjBqSkSWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] [java] - gRPC ThreadPoolExecutor and bounded queue

[info]

Hi everyone,

Our gRPC server runs on a ThreadPoolExecutor with a corePoolSize of 4 and a 
maximumPoolSize of 16. In order to have the pool size increase, we provide 
a BlockingQueue with a bounded size of 20. 

Sometimes short bursts happen and we're perfectly fine with dropping 
requests at this moment, we provided a custom RejectionExecutionHandler 
that increases a counter we are monitoring. However, this rejection handler 
is not aware of the request itself, it only sees a Runnable.

My question is: are the requests automatically canceled if they could not 
get queued? Do I need to cancel them manually somehow?

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+unsubscr...@googlegroups.com.
To post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/f6272913-c632-4754-9f05-6abe7b7e2dd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: grpc reconnect

[shafathhusain]

Thanks Li, That helped.

On Thursday, 29 November 2018 00:27:37 UTC+5:30, Menghan Li wrote:
>
> You can set a custom dialer (
> https://godoc.org/google.golang.org/grpc#WithDialer). This dialer is 
> called to create new connections.
>

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/3e2bd96d-e7b0-40b9-8b0a-794ee9004eb0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Recommended gRPC URI scheme

['Jakob Buchgraber' via grpc.io]

Hi,

in our project we want to allow a user to specify a URI to a service 
endpoint via a flag. We support multiple protocols
for talking to service endpoints, including gRPC. The current plan is to 
select the protocol to use based on the scheme
component of the URI.

Do you provide any guidance as to what name to use for the scheme? I was 
thinking "grpc" and "grpcs" to be
reasonable to choices.

Thanks,
Jakob

-- 
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 post to this group, send email to grpc-io@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/c1ba050c-d014-4008-9b31-421021f02ac7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.