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.
Thank you!
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
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
Hello,
On 05/21/2009 11:16 AM, Alex Balashov wrote:
Daniel,
Thank you. Is this due to retransmissions of ACKable replies?
yes, that could cause it.
Cheers, Daniel
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