<div class="gmail_quote"><div>Hi Bogdan,</div><div>Thanks for the reply. I use the fr_timer as 3 seconds in my script and I am also using failure routes extensively to failover my calls to multiple destinations. Can this be a cause for the race event?</div>
<div>Is there anything else that I can look at to avoid this race event?</div><div><br></div><div>Thanks for all your help !!</div><div><br></div><div>--- Jayesh</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Jayesh,<br>
<br>
the number refers to a timer list (type):<br>
0 FR_TIMER_LIST<br>
1 FR_INV_TIMER_LIST<br>
2 WT_TIMER_LIST,<br>
3 DELETE_LIST,<br>
4 RT_T1_TO_1,<br>
5 RT_T1_TO_2,<br>
6 RT_T1_TO_3,<br>
7 RT_T2,<br>
<br>
4 - is first retransmission timer , while 0,1 are final response timers.<br>
<br>
The message meas that transaction module tried (in one process) to arm<br>
again a timer which was just reset (by other process) - it is a race<br>
between 2 events - re-arming and reseting the timer, Ex: re-arming<br>
retransmission timer while a reply came and stop retransmissions.<br>
<br>
Regards,<br>
Bogdan<br>
<br>
Jayesh Nambiar wrote:<br>
> Hi All,<br>
> I see a lot of similar messages in my syslog:<br>
> CRITICAL:tm:set_timer: set_timer for 4 list called on a "detached"<br>
> timer -- ignoring: 0x2aaaad32f650.<br>
><br>
> Although i don't see any problems in my call processing and I<br>
> understand I can safely ignore it, but can someone please make me<br>
> understand the significance of the integers used in these messages.<br>
> Like in the above message the integer is "4", i have earlier seen<br>
> these messages with integers 0 and 1 and at that time I used to have<br>
> serious problems of opensips not processing requests because of a lag<br>
> in DB queries !!<br>
><br>
> Explanation of these integers and their significance will be very<br>
> helpful.<br>
> Thanks,<br>
><br>
> --- Jayesh<br>
><br></blockquote></div>