You should have no problems with this approach, but it also shouldn't be necessary. gRPC already uses HTTP2 pings to keep channels alive while they're otherwise idle. If you're still seeing disconnects, there are a couple of channel options you can set (they go into an object in the third argument to the Client constructor). The list of them is defined here: https://github.com/grpc/grpc/blob/master/include/grpc/impl/codegen/grpc_types.h#L148. Specifically, modifying "grpc.http2.min_time_between_pings_ms" and "grpc.http2.max_pings_without_data".
In addition, gRPC automatically reconnects dropped TCP connections, so if
your channel is idle with no ongoing calls, you shouldn't even notice
connection drops.
On Tue, Feb 14, 2017 at 7:36 PM Francesco Lazzarino <flazzar...@gmail.com>
wrote:
> Hi,
>
> The current node.js module doesn't allow one to pass a Channel object to
> build a client, but it does allow one to access a channel via
> grpc.getClientChannel(…) and .$channel on a client object.
>
> In lieu of an exposed interface to pass a connection or channel, I tried
> out the following hack to allow two clients to share the same channel.
>
> function combineChannels(aClient, bClient) {
> var aChan = grpc.getClientChannel(aClient);
> var bChan = grpc.getClientChannel(bClient);
> if (aChan.getTarget() != bChan.getTarget()) {
> throw "different targets: " + " (a) " + aChan.getTarget() + "; (b)
> " + bChan.getTarget();
> }
>
> if (aChan.getConnectivityState() != 0) {
> throw "bad connectivity state (a): " +
> aChan.getConnectivityState();
> }
>
> if (bChan.getConnectivityState() != 0) {
> throw "bad connectivity state (b): " +
> bChan.getConnectivityState();
> }
>
> bChan.close();
> bClient.$channel = aChan;
> }
>
> Observing with nettop (macOS) shows only 1 connection when hack is in use,
> and 1 per client otherwise. It seems to work as expected, but is any danger
> in doing so? Is there a better way to accomplish this in node.js?
>
>
> FWIW my goal is to have a healthcheck client keep the TCP socket alive in
> case a LB or FW wants to close idle-long-running connections.
>
> Thanks in advance,
>
> – Franco
>
> --
> 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/a5f6c9ea-48e4-4d68-a5ab-322c55c15f21%40googlegroups.com
> <https://groups.google.com/d/msgid/grpc-io/a5f6c9ea-48e4-4d68-a5ab-322c55c15f21%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> 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-4dkczkAHZJv_-7yg_EHf1DeHuuR0FAQ_hj8P%2Bc4rRpvfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
