Hello,

On 6/19/12 8:50 PM, Alex Balashov wrote:

Hi,

I use 'rtimer' and 'mqueue' to asynchronously defer certain heavy DB tasks on which call processing does not depend.

I was hoping to get a clarification on the exact behaviour of 'rtimer' when tasks don't complete as fast as they should.

Let's say that I set the rtimer route interval to half a second (500 ms), as afforded by new Kamailio 3.3.0 capabilities. What happens if the tasks I am running inside the rtimer route don't complete in that interval? Is that rtimer thread forceably terminated, or is it allowed to run as long as necessary to complete the task? Is there an absolute timeout? If the latter, I assume that another, parallel rtimer route will be started in the background after 500 ms. I am given to understand that there is a thread pool. How big is it? Can I configure its size anywhere? Is there a practical limit?

Finally, is there 100% assurance that 'mqueue' is safe to consume for multiple rtimer processes, possibly ones tripping over each other due to unpredictable delays? Or is it designed only to provide blocking mutex for data passed from a SIP worker thread to a different kind of thread?

there is no threads pool, it is one process started by rtime that consumes the tasks and there is no timeout on the execution of that task. Of course, you can start many rtimer processes to do same task, up to you, via configuration parameters. A matter of how rtimer executed route is built, a rtimer process may not rest (e.g., sleep) and keep consuming mqueue items as long as the queue is not empty.

Consuming mqueue is save if done in paralel by many processes. Fetching the first item means removing it from the linked list to be available only on the local process (very fast operation), then the shared queue list is again available for adding/fetching by other processes.

Cheers, Daniel