On 07/25/2012 03:32 AM, Alex Balashov wrote:
On 07/24/2012 02:59 AM, Daniel-Constantin Mierla wrote:
The way mqueue is consuming items from queue does not ensure queue locking until all items are consumed. So the first item there is removed from queue and cloned in private memory where is accessible via PV, then the queue is unlocked so others can consume or add to it.
Not being in office for few days, I cannot run tests myself ... do you have heavy writers? Can you add few more timer processes to consume from queue and see what happens?
I figured it out; Alex Hermann nailed it. The number of accounting events I was generating was tripping max_while_loops. I thought I had it set high enough, but I guess I didn't. I didn't catch the log message because it was being lost in thousands of lines per second of logging.
There is an occasional situation where the queue empties out, while(mq_fetch(...)) returns false, and an instant later, something is added back to the queue, but now we must wait 1 rtimer task interval for event writing to resume.
However, the ability to do microsecond-based intervals in Kamailio 3.3 has made this problem largely irrelevant. :-)