[Kamailio-Devel] [Kamailio-Users] "Detached" timer messages.

[Daniel-Constantin Mierla]

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
>>
>>     
>
>
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com/