On Fri, Aug 4, 2017 at 7:44 AM, <cr2...@gmail.com> wrote:

> 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=Status{code=UNAVAILABLE, description=null,
> cause=java.io.IOException: Connection reset by peer
>

To others seeing this, there are two places you can see this error: in a
Status or in logged. In the next grpc-java release (1.6) these errors will
be squelched from being logged, but you can still see in in the Status.

I've asked them to try the keepAliveTime and keepAliveTimeout and I'm not
> sure yet if they've done that yet.
>

Something ("in the network") is killing the connection after 20 minutes;
that may be proxies, firewalls, or routers. Most of the time keepalive will
fix this. There is a chance that the TCP connection is being killed because
of its age instead of inactivity; keepalive won't fix that.

The server side is GO 1.40
> ...
> So barrage of questions:
>
> Any thoughts on what is happening here ?  I know not a lot of details for
> you to go on :(
>

You mentioned the client configuration. How about the server. Is it
using MaxConnectionAge? It's possible that there's a bug in the
implementation and it isn't gracefully shutting down the connection. (Or
maybe the Grace timeout is exceeded)

(Note that MaxConnectionIdle has "idleness" defined at a higher level; it
is the time since the last RPC completed, not the last network activity. So
it is unlikely to cause a problem.)

The Java client is moving to the very latest version.  Are there concerns
> with compatibility we need to keep in mind with GO server side ?
>

No. Things should work fine.

Are there timeouts were the underlying connections are closed due to
> inactivity?  I would assume they'd reconnect under covers if so, would the
> keepAlive help here ?  Other options to try?
>

The Channel should reconnect automatically (and if it isn't that's a really
big bug; please file an issue). However, when the connection dies any RPCs
on that connection fail with the Status you see. But if you did another RPC
immediately after, gRPC should attempt to reconnect and everything "just
work."

I noticed on ManagedChannel getState and notifyWhenStateChanged  These
have @ExperimentalApi
> and *Warning*: this API is not yet implemented by the gRPC
> So I assume they really can't be used in latest version to auto retry
> setting up connections when they get disconnected?
> <https://grpc.io/grpc-java/javadoc/io/grpc/ExperimentalApi.html>
>

The reconnect part of that API is when you want a connection to be
available, but aren't sending RPCs. The requestConnection of
getState(true) "acts"
like you sent an RPC (so it brings up a TCP connection if there isn't one),
without actually sending an RPC. Even if implemented, it wouldn't be
necessary.

And yes, the API is still unimplemented. In 1.6 more of it will be plumbed,
but it still may not be functioning quite right. The API really only has
two uses though: 1) notify the application that the Channel is unhealthy
and 2) allow the application to cheaply (without sending an RPC) cause a
connection to be established.

-- 
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/CA%2B4M1oOdi3RWfKBV%2BkZt57MYZ6GyLtvDSskvwCByZ1HqX60Gdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to