Daniel,
Thank you. Is this due to retransmissions of ACKable replies?
Thanks,
-- Alex
Daniel-Constantin Mierla wrote:
Hello Alex,
On 05/21/2009 03:51 AM, Alex Balashov wrote:
Greetings,
I was wondering if someone fluent in the anatomy of the TM module can
tell me what this condition actually implies in a commonsensical sort
of way, from a user perspective -- it is on line 861 in
modules/tm/timer.c:
/* check first if we are on the "detached" timer_routine list,
* if so do nothing, the timer is not valid anymore
* (sideffect: reset_timer ; set_timer is not safe, a reseted
timer
* might be lost, depending on this race condition ) */
if (new_tl->timer_list==DETACHED_LIST){
LM_CRIT("set_timer for %d list called on a
\"detached\" "
"timer -- ignoring: %p\n", list_id, new_tl);
goto end;
}
Reason I am wondering is that I got a few of these error messages in
my logs:
May 20 18:23:50 ser1 /usr/local/sbin/kamailio[25232]:
CRITICAL:tm:set_timer: set_timer for 1 list called on a "detached"
timer -- ignoring: 0x2a96cc0d50
And was not sure what to make of them.
you can ignore it. I think in the past were discussions to lower the
critical level to something line warning. This happens because of a race
between replies. The transaction is removed from timer by one reply or
timeout and another one comes in trying to process and add it back to
timer.
Cheers,
Daniel