Re: [reSIProcate] An other Ares problem

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Great catch - not sure why no one else has noticed this - it appears this code has been like this since 2010 - but I can see exactly what you are describing by just looking at the code.

I'm thinking the time should be initialized to be as high as possible.  Can you try out the following code and see if it works good for you?

unsigned int

AresDns::getTimeTillNextProcessMS()

{

   struct timeval tv;

   unsigned maxSystemTime = resip::Timer::getMaxSystemTimeWaitMs();

   tv.tv_sec = maxSystemTime / 1000;

   tv.tv_usec = 1000 * (maxSystemTime % 1000);

   ares_timeout(mChannel, NULL, &tv);

   return tv.tv_sec*1000 + tv.tv_usec / 1000;

}

Thanks!

Scott

On Wed, Feb 19, 2014 at 3:41 AM, Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> wrote:

Hi,
We tried out 1.9 multi-threaded and got 100% load in the dns thread. It
turned out that ares_timeout will not touch the tv struct if no work is
on going. This means that the timeout is calculated on comletely random
data.
This patch fixes the problem, I'm not sure about a suitable time though.

Best Regards,
Björn A.

*** AresDns.cxx.orig    2014-02-19 09:34:23.000000000 +0100
--- AresDns.cxx 2014-02-19 09:35:24.000000000 +0100
*************** AresDns::makeRawResult(void *arg, int st
*** 598,604 ****
  unsigned int
  AresDns::getTimeTillNextProcessMS()
  {
!    struct timeval tv;
     ares_timeout(mChannel, NULL, &tv);
     return tv.tv_sec*1000 + tv.tv_usec / 1000;
  }
--- 598,604 ----
  unsigned int
  AresDns::getTimeTillNextProcessMS()
  {
!    struct timeval tv = {30,0};
     ares_timeout(mChannel, NULL, &tv);
     return tv.tv_sec*1000 + tv.tv_usec / 1000;
  }



_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel