Java grpc connection state

[cr2...@gmail.com]

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?

[Spencer Fang]

Are you using Java gRPC? There's a method you can call to query for the current state:

https://grpc.io/grpc-java/javadoc/io/grpc/ManagedChannel.html#getState-boolean-

On Sat, Mar 3, 2018 at 10:33 AM <cr2...@gmail.com> wrote:

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 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/e8b9bcd0-7318-4128-b4b6-d6aea19cdd96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Spencer Fang

[cr2...@gmail.com]

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 managed channel still seems to just reporting IDLE.

When if ever would it go from IDLE  back to READY?

Will it only go to SHUTDOWN when there is an explicit shutdown done on the channel ?

So for a channel that is READY is the only thing I need to look at is when it moves out of the READY state I should make a new connection ?

Thanks!

[cr2...@gmail.com]

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:

[Spencer Fang]

Here's a document that describes the allowed state transitions https://github.com/grpc/grpc/blob/master/doc/connectivity-semantics-and-api.md that should answer your questions.

gRPC tries to manage connections for you, so you can assume the channel will become ready when you perform an RPC. 

--

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/479124a7-c8f3-4938-807e-ab795b48b3e8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Spencer Fang

[Eric Anderson]

On Mon, Mar 5, 2018 at 11:16 AM, <cr2...@gmail.com> wrote:

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.

On Mon, Mar 5, 2018 at 11:28 AM, <cr2...@gmail.com> wrote:

I should have pointed out that when queried the state I was using .getState(true);

To close the loop here, we've reproduced a bug that would impact this conversation: https://github.com/grpc/grpc-java/issues/4170 . getState(true) is currently broken and does not trigger a connect if the channel was previously connected (there's a few cases it still will, but they will be uncommon). It does work properly for a new channel, but not for reconnecting.

Note that we still properly reconnect when doing an RPC. It's only the getState(true) API that is broken.

[cr2...@gmail.com]

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 prioritize which endpoints are most likely to succeed to try them first.  Nothing I did took an IDLE to RUNNING except an actual RPC but then that would be too late.  

[Eric Anderson]

On Tue, Mar 6, 2018 at 3:59 PM, <cr2...@gmail.com> wrote:

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 prioritize which endpoints are most likely to succeed to try them first.  Nothing I did took an IDLE to RUNNING except an actual RPC but then that would be too late.

As a note, your use-case may be better served by implementing a LoadBalancer. It would get to choose which endpoint to use, and has access to "subchannel.requestConnection()" (which should be working even though getState(true) is not). You can see PickFirstBalancerFactory for an example. Choosing to make your own LB mainly depends on how much application logic you need as part of your decision (although you can also plumb application data to the LB via CallOptions.withOption).