<p dir="ltr">The destinations don't have dns resolution problems. They resolve their target name once and at every reconnect. On the source side you have a potential name lookup for every message (if uncached of course).</p>
<p dir="ltr">Or you mean that the target server cannot be resolved? Why not add it to /etc/hosts? Initiating a reconnect is handled in the main thread, thus name resolution of the target server would block other threads as well.</p>
<p dir="ltr">The basic problem of name resolution is on the source side though, there each incoming message can have an associated dns cache miss but that's delegated to the workers.</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday, August 24, 2015 7:31 AM, <a href="mailto:syslog-ng-bounces@lists.balabit.hu">syslog-ng-bounces@lists.balabit.hu</a> wrote:<br>
> sources/destinations are worked on by a set of worker threads, which<br>
> are not dedicated to a source or destination.<br>
><br>
> DNS resolution happens at the input side, so if you have multiple log<br>
> statements, it will only happen once, right after reception, on the input side.<br>
><br>
> however, if you only have one udp() source, that will only use one<br>
> worker at a time, so if you have multiple threads the others will not be affected.<br>
><br>
> hope this helps.<br>
<br>
;) Not sure. First off, my UDP DNS resolution concern is in relation to a *destination* definition.<br>
<br>
destination d_NAaudit_Prio { file("/var/log/zzz/audit_log" template(t_NAFormat_Prio)); udp("testing" port(514) template(t_NAFormat_Prio)); };<br>
<br>
This same destination is used in several log statements, the main one of which is in a fairly complex log statement with multiple junction definitions (see the genesis of this in the following mailing list thread: <a href="https://lists.balabit.hu/pipermail/syslog-ng/2014-April/021330.html" rel="noreferrer" target="_blank">https://lists.balabit.hu/pipermail/syslog-ng/2014-April/021330.html</a>).<br>
<br>
So it isn't entirely clear to me how a statement definition like this results in a specific thread breakdown... Would isolating this destination to its own thread be as simple as adding "threaded" to the flags option for this destination (and then any of the referenced "log" statements would be running in their own threads), or does this happened by default (in v3.6.x)?<br>
<br>
Apologies if I'm missing something obvious here ;).<br>
______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" rel="noreferrer" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" rel="noreferrer" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
</div>