Grpc-node: Clarifying proper usage of grpc client connection

[badoet]

1. Does grpc-node automatically support connection pooling?
   e.g. const sessionService = new client.Sessions(serviceURL, grpc.credentials.createInsecure())
   calling this new client.Sessions multiple time will it automatically bind it to the same channel underneath? or will it create multiple channels?

2. Do we need to close client connection after use?
   e.g. if i dont call sessionService.close() after usage, what happen to it?
   and if i create another sessionService without closing the previous will this mean it will just hold the connection open and cause memory leak?

3. Is it common to get load balancing policy error due to the grpc server is restarted?
   i feel that we keep getting this error in our client because we never close the grpc connection and it just keep throwing this error Error: Call dropped by load balancing policy every time we restarted one of the grpc server.

any insight and input is appreciated. i cant find any information on this from the web and documentation.
I am pretty sure there are many people have the same question or face the same problem as us.
thank you in advance

[aajtodd]

I too would ask for some clarification.

The node client API differs from Go/C++/Python/Java/C# API's by not accepting a channel argument in the client stub.

There was this issue opened at one point: https://github.com/grpc/grpc/issues/8515

We have several services on a single server split up by domain. How do we share underlying channels between stubs?

let stub1 = new ClientStub1(url, creds);
let stub2 = new ClientStub2(url, creds);

It would be nice to have the option of specifying the underlying channel

let client = new grpc.Client(url, creds);
let chan = client.getChannel();

// factory method?
let stub1 = ClientStub.fromChannel(chan);

// pass as an option?
let stub2 = new ClientStub("", null, {channel: chan})

I tend to agree with the referenced issue that the stub and channel creation should be separate the way it is for other languages.

[zephyrpersonal]

@aajtodd our team meets the same problem as yours. A single server provides several services and by client side we create multiple stub instances.

As @murgatroid99 had explained in the grpc/grpc#8515 that

Already, if you construct two clients with the same server address, options, and the same credentials object (or insecure credentials), the underlying connection is shared.

I agree it would be nice if some more detailed clarification could be given because I'm a C++ amateur and can't dive deep into the ext source files...

[nicolasnoble]

We took a long time trying to debate how to answer this because there's multiple, nested questions in there that are a bit difficult to parse. In the future, I would encourage to create separate issues for different questions, or to at least avoid bundling them all up like that.

1. Basically, yes. If you create two clients that are basically pointing at the same server, they'll both share connections. "Reusing a channel" might be a misnomer in the sense that the grpc engine will still decide what to do eventually.

2. See 1, but I'm not entirely sure I understand what you mean. It really depends on what you do and what you want to achieve. If the intend is to reuse connections over different services, by all means create as many services as you need; connection sharing is there for that. If however you are "finished" with the first one and just need to proceed with a new one, it's better to close the previous one, of course, especially if you're going to hit a different server. If you don't close, there'll be lingering resources being used until the garbage collector eventually collects the object if you don't have any reference to it anymore.

3. I'm not really getting what you're asking. The error basically means the server is being restarted, yes, so this is kind of expected.

[nicolasnoble]

No updates in more than a month, closing.