Since the root cause of connection failure is misconfiguration there is no chance it can be solved sooner than next reload of configuration cache by server. It makes no sense to continue polling mis-configured passive proxy until then.

the misconfiguration could be on the proxy side, right (the TLS scenario) ? in that case it could have been resolved sooner than the next config cache update.
non-numeric port is unlikely to be solved, but in that case maybe it's better to validate this when building the config cache and not even attempt such a connection ?

Changes here will apply only to cases when TLS had not been included onto configuration of server or port is specified as non-existing macro. So this all is server side specific when the intention is to use passive proxy.

sort of blacklisting known bad cases ? if so, sounds great - thank you for the update.

maybe it's better to validate this when building the config cache

That's arguable for the following reasons:

1. config cache update blocks the whole operation of Zabbix server/proxy, situation has improved, but still, not good to add additional checks here;
2. config cache operations and logging are both using mutexes, there is a chance of deadlocks if they are mixed up without care.

Maybe it's better to not let faulty configurations into DB. I'm looking at you, API

a very good point. i don't have a solution for it, unfortunately.
parallel, non-blocking cache build process has been discussed, but it would double the memory usage for the cache.
even if api was improved, or even moved into the server, a bit of defensive programming could be helpful - unexpected config has always appeared in the db. the more resilient the server is to that, the better.

Successfully tested. See proposed modifications in r77155, r77157, r77158, r77159, r77163, r77164, r77165, r77166.

<viktors.tjarve> These all are good changes. CLOSED

Released in:

• 3.4.7rc1 r77204
• 4.0.0alpha3 r77205