Looking at the “max_conn_time” property
Just a bit confused as to the name of this property vs what the description says “This setting forces a DNS cache flush (in seconds). The default setting is 0.”
So out of the box, default is that once a name is resolved it will never be re-checked (or based on dns ttl?)
If I set this to 30, would that mean that every 30s it does… what exactly?
The code tyk/reverse_proxy.go at e887423ba9276d3c499a3fd4447062f3c758606f · TykTechnologies/tyk · GitHub
Seems to show that it completely re-creates a new http transport object (which I assume is where resolved names are cached?)
How expensive of an operation is this? Impacts on the ability to fulfill requests while this is going on?
Just looking for some more info on it. Thanks
Anyone have any thought son this?
Hi there, I’m looking into this - and indeed, is a little confusing.
This setting should be used in conjunction with
When Tyk initiate keep-alive connection, DNS query made only once per connection but there could be many connections in request pool.
In some cases, when upstream instance is removed from load balancer, but not terminated, it continues receiving traffic from Tyk, since the TCP connection is still active, and nobody terminated it.
This option forces connection to be re-created after a specific amount of time, so Tyk will establish connection to new valid upstream instance.
This is quite specific case, since in most of the cases, when the instance is removed from LB, connection is terminated properly.
So while it does not directly relate to DNS caching, it solves related issue caused by IP caching.