Open renbojiang opened 6 years ago
we are using confd-0.16.0-linux-amd64
I believe the "long connection" is due to our use of the Consul DefaultConfig()
function which will pool and reuse idle connections to Consul.
// DefaultConfig returns a default configuration for the client. By default this // will pool and reuse idle connections to Consul. If you have a long-lived // client object, this is the desired behavior and should make the most efficient // use of the connections to Consul. If you don't reuse a client object , which // is not recommended, then you may notice idle connections building up over // time. To avoid this, use the DefaultNonPooledConfig() instead. func DefaultConfig() *Config { return defaultConfig(cleanhttp.DefaultPooledTransport) }
Perhaps we should consider implementing the DefaultNonPooledConfig()
function when confd is running in the default interval
mode and only implement DefaultConfig()
when confd is running in watch
mode.
// DefaultNonPooledConfig returns a default configuration for the client which // does not pool connections. This isn't a recommended configuration because it // will reconnect to Consul on every request, but this is useful to avoid the // accumulation of idle connections if you make many client objects during the // lifetime of your application. func DefaultNonPooledConfig() *Config { return defaultConfig(cleanhttp.DefaultTransport) }
It seems the connection between confd and consul is long connection. once the connection is created, even consul restart, the connection will not be re-created. It causes all changes of consul will not be detected by confd.