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 acces
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 ot
On 07/24/2012 04:20 AM, Alex Hermann wrote:
On Tuesday 24 July 2012 04:46:43 Alex Balashov wrote:
So, perhaps my issue comes down to the while() loop breaking before the
queue is truly empty. That is, unless those thousands of records are
somehow showing up between the while() condition evalua
On Tuesday 24 July 2012 04:46:43 Alex Balashov wrote:
> So, perhaps my issue comes down to the while() loop breaking before the
> queue is truly empty. That is, unless those thousands of records are
> somehow showing up between the while() condition evaluation and my log
> statement, which seem
Hello,
On 7/24/12 4:46 AM, Alex Balashov wrote:
On 07/23/2012 08:38 PM, Alex Balashov wrote:
route[ACCT_WRITER] {
while(mq_fetch("acct_write")) {
# Some stuff to write $mqv(...) values to PostgreSQL.
...
sql_query("ca", "SELECT * FROM acct_event_
On 07/23/2012 08:38 PM, Alex Balashov wrote:
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
Okay, ignore this bit. I had a conflicting timer that I forgot about
that was engaged at a 5 sec interval, thus polluting the results. When
I run my pure while() loop test routine and only it, it does not
demonstrate this loop-breaking behaviour.
It still doesn't explain what is going on wit
Yeah, something's going on interrupting the execution of the route. I
set the interval to 1:
modparam("rtimer", "timer", "name=test;interval=1;mode=1")
And then added this to the infinite for() loop in
timer_proc.c:fork_basic_timer(), after the call to the timer_function:
I think some sort of execution time governor in the actions
infrastructure is probably the right angle here.
I added a log statement to modules_k/rtimer/rtimer_mod.c:stm_timer_exec():
for(rt=it->rt; rt; rt=rt->next)
{
fmsg = faked_msg_next();
if (
I did an experiment to try to simplify the problem, and rule out mqueue
concurrency/locking issues:
modparam("pv", "shvset", "lasttm=i:-1")
modparam("rtimer", "timer", "name=test;interval=1;mode=1")
modparam("rtimer", "exec", "timer=test;route=TEST_ROUTE")
route[TEST_ROUTE] {
On 07/23/2012 08:38 PM, Alex Balashov wrote:
mq_pv_free("account_write");
This is a typo, btw.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/, http://ww
I am wondering if the execution time of a route is somehow bounded in
action.c/run_actions(). Unfortunately, I don't enough about how it
works to figure it out.
On 07/23/2012 08:38 PM, Alex Balashov wrote:
Hi Daniel,
I wanted to go back to this thread for a minute:
http://lists.sip-rou
12 matches
Mail list logo
