----- Original Message -----
> 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

Hello.

I would like to ask you for a feedback for the patch I sent you
last time, so I can proceed with it, or fix found issues.

Thanks!

Regards,

-- 
Tomas Hozza
Software Engineer - EMEA ENG Developer Experience

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