Tyk not reresolving DNS between requests

Hi All,

We’re still on Tyk 1.9 for now

I’m aware that Tyk 1.9 has service discovery support, and we’ll probably move to using that shortly. However, just wanted to confirm my suspicions about an issue we had recently with our current setup.

At the moment we’re just setting the “Target URL” to be a consul-provided DNS address, and behind that consul address is actually two servers.

We’re seeing that only one server is receiving the traffic that is sent through Tyk.

My current theories are:

a) Tyk is caching the results of the DNS entry - so it’s not reresolving the DNS for each request. If this is the case, what circumstances cause the DNS to be reresolved?

b) the DNS address is always giving the same list in the same order meaning Tyk always forwards to the same node (I’m less convinced by this one, if I do ping $CONSUL_ADDRESS then it alternates between the two nodes as I’d expect.)

Thanks,

Tyk doesn’t explicitly cache DNS data, it hands off to golang’s net/http library which handles the eventual call that goes out, which includes a resolution step AFAIK, looking around I can see that apparently they do not do any caching.

Do you have Tyk explicitly closing connections (it’s an option in the tyk.conf) - it might be re-using an existing TCP connection and recycling for further requests?

I can’t speak to this, this sounds essentially like DNS load balancer, so the resolution should just round robin at the DNS level, not at the client level?

We don’t set anything in tyk.conf about closing connections - so I’d guess you’re right with that!

I’m just changing our provisioning scripts to make use of the service discovery system, seems to make a lot more sense and should ensure things are balanced intelligently…

Thanks for the speedy response,

It can help with high-traffic installs, as you may run out of file handles quickly:

close_connections
Set this value to true to force Tyk to get clients to close the connection with the client, otherwise the connections will remain open for as long as your OS keeps TCP connections open, this can cause a file-handler limit to be exceeded.

Just add "close_connections": true to the root of the configuration object.