I agree that this seems outside of the scope of the grpc library. But +1 that you could in theory use a custom name resolver to implement some behavior like this.
Also +1 that the --clear-on-reload plus SIGHUP option may be useful here. I'm curious though: suppose you can flush the local DNS cache, can you guarantee that there are no more caches upstream? On Wednesday, July 12, 2023 at 10:38:27 AM UTC-7 Richard Belleville wrote: > > Depending on which language you're using, you could use the custom name > resolver interface <https://grpc.io/docs/guides/custom-name-resolution/> > to implement this behavior yourself. > On Wednesday, July 5, 2023 at 12:53:43 PM UTC-7 Gmail wrote: > >> Thanks Frederic >> I understand that. But I only want to do it when grpc has a connection >> failure. Is there an already existing mechanism to do that.? >> >> On Jul 5, 2023, at 12:37 PM, Frédéric Martinsons <frederic....@gmail.com> >> wrote: >> >> >> >> I think this is totally unrelated to grpc but for what it worth, if you >> control your dnsmasq, you can use --clear-on-reload option and send a >> SIGHUP to dnsmasq process to reload the cache. >> >> Le mer. 5 juil. 2023, 21:24, Ramanujam Jagannath <jag...@gmail.com> a >> écrit : >> >>> Backgrounder - Our device connects to an AWS static IP. We use dnsmasq >>> on device to provide lookup services for downstream devices. Currently we >>> are planning to use a long. DNS TTL on AWS to avoid too many DNS lookups >>> from on field devices. The on-field devices use a grpc connection to >>> maintain long standing tcp connections. We do have multiple availability >>> zones and so a DNS resolution does return 4 IP addresses >>> >>> Problem - When an IP address fails(on AWS) the grpc client will retry >>> and re-resolve. But because we have dnsmasq on device it will send a cached >>> address - which is potentially faulty. >>> >>> Solution - This can be resolved by flushing the dnsmasq cache on device. >>> But is there a way to flush the dnsmasq cache on device on connection >>> failure only? grpc under the hood uses c-ares which in our case goes to the >>> dnsmasq proxy on device. >>> >>> Any solutions/thoughts. Someone must have encountered this problem >>> before? >>> >>> -- >>> 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 view this discussion on the web visit >>> https://groups.google.com/d/msgid/grpc-io/75d68762-eb58-4400-b8e1-3584f6bd6e51n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/grpc-io/75d68762-eb58-4400-b8e1-3584f6bd6e51n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/4a0815f5-f70a-4ee4-8b8c-77e8ea8a7909n%40googlegroups.com.
