Hi Daniel,
I wanted to go back to this thread for a minute:
http://lists.sip-router.org/pipermail/sr-users/2012-June/073663.html
Sorry that I didn't reply to the thread; I no longer have the last message.
In your reply, you said:
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."
However, I am seeing some behaviour that is rather different.
Roughly, I have a single rtimer task that runs every 3 seconds and consumes an mqueue full of accounting events. The rtimer request route looks like something this:
route[ACCT_WRITER] { while(mq_fetch("acct_write")) { # Some stuff to write $mqv(...) values to PostgreSQL.
...
sql_query("ca", "SELECT * FROM acct_event_proc(...)"); ...
mq_pv_free("account_write"); } }
And the rtimer task is parameterised thusly:
modparam("rtimer", "timer", "name=acct_write;interval=3;mode=1") modparam("rtimer", "exec", "timer=acct_write;route=ACCT_WRITER")
And the mqueue:
modparam("mqueue", "mqueue", "name=acct_write")
I have a stored procedure - let's call it acct_event_proc() - that is invoked from within the rtimer task. When I looked at the live query activity from Kamailio to Postgres by doing a packet capture on loopback, like this:
tcpdump -i any -A -s 0 -tttt -n 'tcp port 5432' | grep acct_event_proc
What I saw was some events being written for about ~3 seconds and then the process would stop. Then, after about half a second, it would burst again for 3 seconds, then stop again. And so on and so forth.
When I lowered the interval to 1 second, it got faster and more responsive, and would push more events through in one interval. But still, it appeared to be a limited "burst" of SELECT calls punctuated by 1 second of silence.
When I checked out branch 3.3 and lowered the interval to 50000u, it got even faster, almost real-time enough to keep up. Still, I did not really know what was happening, so I added an MI command to HEAD to check mqueue size live:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commit;h=41f7715...
(I think it would be quite useful anyhow, as there is no runtime mqueue info available right now.)
Using it, I confirmed my impression: the bigger the rtimer interval, the larger the queue grows, and the slower the events seem to be written overall. The shorter the rtimer interval, the faster they are dequeued, and the smaller the mqueue is overall, in the course of normal call processing.
Thus, my impression is that the execution time of the rtimer task is bounded by the interval, and that the core kills the forked rtimer task currently running prior to starting another one.
Can you shed some light?
Thanks!
-- Alex