Hi Evan.

Thank you for your reply and advices.

----- Original Message -----
> Hi Tomas,
> 
> > Is there any specific reason for this? Would you be OK with having
> > a configuration option(s) in the 'lwres' statement that would
> > enable setting the NTASKS/NRECVS to a different value?
> 
> No, there's no particular reason for that.  The lightweight resolver
> never got much widespread adoption, so it's been neglected.  (Nobody
> uses it -> nobody complains about it -> we don't fix broken things.
> You know how it goes.)
> 
> We've actually considered deprecating it, and may yet do so,
> but in the meantime I'd be happy to accept your patch.  There's a
> system test in bin/tests/system/lwresd that might be an appropriate
> place for any regression tests you wish to add.  Documentation
> goes in chapter 5 of the ARM: doc/arm/Bv9ARM-book.xml.

I implemented the new options and added documentation (which may require
some polishing. However I can not think of any use-case that I can add
into regression tests for those new options. If you have some idea I
can add some.

> > Do you have any specific requirements on how such options should
> > be named?
> 
> I would suggest they include "lwres", to clarify that these options
> only affect lightweight resolver tasks.  I might use "lwres-tasks"
> and "lwres-clients", for instance, with "lwres-tasks" defaulting to
> ns_g_cpus (the number of CPUs, potentially overridden by the '-n'
> option).  Clients would then be evenly divided amongst the tasks.
> Up to you, though.
> 
> > Should there be any (maximum) limit for the values?
> 
> Well, at some point you'd hit system resource limits.  Offhand, I'd
> suggest putting the maximum at 32768 clients, and default to 1024.
> Perhaps consider using a lower default when running as named and a
> higher one when running as lwresd.

I followed your advices and added appropriate default/maximum values.
Please see the commit message.

> The way clients work in lwresd is, unfortunately, broken and stupid.
> In named, when it's necessary to recurse to answer a client query, the
> ns_client object that handled the incoming query will replace itself
> so that if more queries come in while it's recursing, there will be
> another ns_client object there to handle them.  The lwd_client
> objects used for the lightweight resolver don't do this.  If you get
> them all busy doing recursion, all incoming queries are starved.
> If we don't end up deprecating LWD, then one of these days we really
> ought to combine its client-management code with ns_client.
>
> --
> Evan Hunt -- each@isc.org
> Internet Systems Consortium, Inc.
 
If you see anything in my patch that could be improved, please let me know.

Thank you!

Regards,
-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
Red Hat Inc.                               http://cz.redhat.com