NodeJS client, can't seem to use SRV records for service discovery

[craigf...@gmail.com]

Hello,

I'm building my first gRPC service and I'm having trouble on the service discovery side.  As an alternative to using a Layer 3 load balancer I'm trying to use a set of SRV records.  Both server and client are in NodeJS, and I'm using whatever is installed using "npm install grpc", version flag "^1.12.3".

My understanding from reading the code is that this is implemented in the c-ares DNS implementation but not the native DNS implementation, but I can't seem to get the client runtime to load the c-ares DNS implementation.  I've attempted both running natively on macOS and via a container using node:8-slim as the base.

I've proved that my container can resolve the DNS entry properly, which I've set up using dnsmasq on my host machine.

$ docker run --dns 192.168.1.22 -e GRPC_TRACE=all craigf/service:latest dig srv service.craigf.local

<SNIP>

;; ANSWER SECTION:

service.craigf.local. 0 IN SRV 0 0 5000 192.168.1.22.

(My server is bound to port 5000 on my host machine)

My client code is creating it's client like this:

var client = new Health(

    'dns:///service.craigf.local',

    grpc.credentials.createInsecure(),

    {

        'lb_policy_name': 'round_robin'

    }

);

But the logs are always showing "dns_resolver.cc:339]        Using native dns resolver", even when I attempt to force the c-ares implementation using GRPC_DNS_RESOLVER=ares.  My test client eventually times out with a "Name resolution failure" message.

What am I missing here?'

Thanks,

Craig

[Michael Lumish]

The actual problem here is fairly simple: we haven't yet implemented the glue code to make the cares resolver work with the Node library. The Node library uses different low-level networking code to integrate more closely with Node's own event loop and network stack, and that includes alternative name resolver code paths. It's on our list of things to do but so far other tasks have had higher priority. We would welcome external contributions to improve this.

--
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/2695388c-9dec-4be6-a913-b78f8e56b0ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[craigf...@gmail.com]

Thanks Michael,

Is there a platform feature matrix published somewhere?  That would help identify which features aren't even implemented so folks don't chase their tails trying to configure them.

Regards,

Craig

[Kailash Sethuraman]

Hi Craig

We do not yet have such a matrix published. What we do today is to state in release notes when a language rolls out support for a particular RFC.

We can break down a matrix at a  gRFC/ language level --  will that help?

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c83821d3-1429-457c-b30c-c598620e452b%40googlegroups.com.

[Craig Forster]

That would be amazing!