configure connect timeout for grpc java client?

4,163 views
Skip to first unread message

Elhanan Maayan

unread,
Dec 19, 2019, 2:57:52 PM12/19/19
to grpc.io
hi... is there a way to configure a connect time out , for example trying to connect to host that's not responding , currently it seems to set to 20 seconds, but i'd like to shorten to 10 seconds where i'll get unavailable 

i've looked every git  issue there is, but it doesn't seem to be implemented or i don't see where it's configured. 

Christoph John

unread,
Dec 19, 2019, 3:56:46 PM12/19/19
to Elhanan Maayan, grpc.io
I think this can be done via the channel options of the NettyChannelBuilder.

NettyChannelBuilder.forAddress( host, port ).withOption( ChannelOption.CONNECT_TIMEOUT_MILLIS, 10000 ).build();

Cheers,
Chris.



On 19.12.19 20:57, Elhanan Maayan wrote:
hi... is there a way to configure a connect time out , for example trying to connect to host that's not responding , currently it seems to set to 20 seconds, but i'd like to shorten to 10 seconds where i'll get unavailable 

i've looked every git  issue there is, but it doesn't seem to be implemented or i don't see where it's configured. 
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/837b141c-a869-48b6-995d-7b969f4c0fdc%40googlegroups.com.


  



Elhanan Maayan
unread,
Dec 20, 2019, 3:20:36 AM12/20/19
to christo...@macd.com, grpc.io
thanks don't how i missed that, i looked on it before, 
btw how can i stop it from retrying?
Christoph John
unread,
Dec 20, 2019, 5:24:50 AM12/20/19
to Elhanan Maayan, grpc.io

  
    
  
  

    Hmm, never wanted to do
      that. But I guess you'll have to shutdown() the channel.

      

      Chris.

    
-- 
Christoph John
Software Engineering
T +49 241 557080-28
christo...@macd.com

MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151 
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald

  



Eric Gribkoff
unread,
Dec 20, 2019, 1:55:02 PM12/20/19
to christo...@macd.com, Elhanan Maayan, grpc.io
Do you actually care about the underlying connection backoff attempts of the channel? From your statement about getting an UNAVAILABLE response within 10 seconds, it sounds like you are primarily interested in your RPCs failing when the connection isn't established within a given time period. For that, you should just set a deadline on your calls. This can be done on a stub via https://grpc.github.io/grpc-java/javadoc/io/grpc/stub/AbstractStub.html#withDeadlineAfter-long-java.util.concurrent.TimeUnit-, where the set deadline applies to all calls on the returned stub - e.g., typical usage would be stub.withDeadlineAfter(<duration>).rpcMethod().

Thanks,

Eric



Elhanan Maayan
unread,
Dec 21, 2019, 11:26:54 AM12/21/19
to grpc.io
this is what we initially did, where deadline was set to 15 seconds, to the deadline triggered first. 

the problem is that it hides the true feedback, unavailable means you have network configuration issue, you were unable to establish a connection to the server, either because the wrong ip, it was unresponsive, firewall etc.. deadline means you didn't get a response from the server.
the fact it starts counting from the moment you called a method and not from the moment you actually connected seems like a bug, because i'd be interested in a dead line being measured form the moment i was actually able to send a signal to the server. 

On Friday, December 20, 2019 at 8:55:02 PM UTC+2, Eric Gribkoff wrote:
Do you actually care about the underlying connection backoff attempts of the channel? From your statement about getting an UNAVAILABLE response within 10 seconds, it sounds like you are primarily interested in your RPCs failing when the connection isn't established within a given time period. For that, you should just set a deadline on your calls. This can be done on a stub via https://grpc.github.io/grpc-java/javadoc/io/grpc/stub/AbstractStub.html#withDeadlineAfter-long-java.util.concurrent.TimeUnit-, where the set deadline applies to all calls on the returned stub - e.g., typical usage would be stub.withDeadlineAfter(<duration>).rpcMethod().

Thanks,

Eric

On Fri, Dec 20, 2019 at 2:24 AM 'Christoph John' via grpc.io <grp...@googlegroups.com> wrote:

    Hmm, never wanted to do
      that. But I guess you'll have to shutdown() the channel.

      

      Chris.

    

    
On 20.12.19 09:20, Elhanan Maayan
      wrote:

    

    

      
      
thanks don't how i missed that, i looked on it
        before, 
        
btw how can i stop it from retrying?

      

      

      

        
On Thu, Dec 19, 2019 at 10:56
          PM Christoph John <christ...@macd.com>
          wrote:

        

        
 I think this can be done via the channel options of the
            NettyChannelBuilder.

            

            NettyChannelBuilder.forAddress( host, port ).withOption(
            ChannelOption.CONNECT_TIMEOUT_MILLIS, 10000 ).build();

            

            Cheers,

            Chris.

            

            

            
On 19.12.19 20:57, Elhanan Maayan wrote:

            

            

              
hi... is there a way to configure a connect
                time out , for example trying to connect to host that's
                not responding , currently it seems to set to 20
                seconds, but i'd like to shorten to 10 seconds where
                i'll get unavailable 
                


                

                
i've looked every git  issue there is, but it
                  doesn't seem to be implemented or i don't see where
                  it's configured. 

              

              -- 

              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 grp...@googlegroups.com.
-- 
Christoph John
Software Engineering
T +49 241 557080-28


MACD GmbH
Oppenhoffallee 103
52066 Aachen, Germany
www.macd.com

Amtsgericht Aachen: HRB 8151 
Ust.-Id: DE 813021663
Geschäftsführer: George Macdonald






-- 

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 grp...@googlegroups.com.
Eric Gribkoff
unread,
Dec 23, 2019, 12:19:39 PM12/23/19
to Elhanan Maayan, grpc.io
Based on your other post, it sounds like you are using wait for ready. I'm unclear on why the client would be willing to wait, say, 1 minute for a connection to establish but only 15 seconds for the server to respond once it receives the RPC. It would seem more reasonable for the client to have a single deadline that applies to the RPC itself, and any server-processing "deadline" can be enforced by the server itself (it knows exactly when it received the RPC). 

If this doesn't apply for your scenario somehow, then you should explicitly - and separately from any particular RPC - monitor the connection state of your channel via https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#getState-boolean- and https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#notifyWhenStateChanged-io.grpc.ConnectivityState-java.lang.Runnable-.

- Eric


To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c664999b-11c1-4db9-a626-59a42128dd27%40googlegroups.com.




Penn (Dapeng) Zhang
unread,
Dec 23, 2019, 1:07:33 PM12/23/19
to grpc.io
I agree with Chris and Eric, you might want to set netty/socket option for a shorter connection attempt timeout, and not to enable waitForReady (by default, waitForReady is not enabled) so that each RPC will fail immediately without waiting if connection attempt fails.


On Monday, December 23, 2019 at 9:19:39 AM UTC-8, Eric Gribkoff wrote:
Based on your other post, it sounds like you are using wait for ready. I'm unclear on why the client would be willing to wait, say, 1 minute for a connection to establish but only 15 seconds for the server to respond once it receives the RPC. It would seem more reasonable for the client to have a single deadline that applies to the RPC itself, and any server-processing "deadline" can be enforced by the server itself (it knows exactly when it received the RPC). 

If this doesn't apply for your scenario somehow, then you should explicitly - and separately from any particular RPC - monitor the connection state of your channel via https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#getState-boolean- and https://grpc.github.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#notifyWhenStateChanged-io.grpc.ConnectivityState-java.lang.Runnable-.

- Eric

Reply all
Reply to author
Forward
0 new messages