Hi Bogdan, 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? Is there anything else that I can look at to avoid this race event?
Thanks for all your help !! --- Jayesh > Hi Jayesh, > > the number refers to a timer list (type): > 0 FR_TIMER_LIST > 1 FR_INV_TIMER_LIST > 2 WT_TIMER_LIST, > 3 DELETE_LIST, > 4 RT_T1_TO_1, > 5 RT_T1_TO_2, > 6 RT_T1_TO_3, > 7 RT_T2, > > 4 - is first retransmission timer , while 0,1 are final response timers. > > The message meas that transaction module tried (in one process) to arm > again a timer which was just reset (by other process) - it is a race > between 2 events - re-arming and reseting the timer, Ex: re-arming > retransmission timer while a reply came and stop retransmissions. > > Regards, > Bogdan > > Jayesh Nambiar wrote: > > Hi All, > > I see a lot of similar messages in my syslog: > > CRITICAL:tm:set_timer: set_timer for 4 list called on a "detached" > > timer -- ignoring: 0x2aaaad32f650. > > > > Although i don't see any problems in my call processing and I > > understand I can safely ignore it, but can someone please make me > > understand the significance of the integers used in these messages. > > Like in the above message the integer is "4", i have earlier seen > > these messages with integers 0 and 1 and at that time I used to have > > serious problems of opensips not processing requests because of a lag > > in DB queries !! > > > > Explanation of these integers and their significance will be very > > helpful. > > Thanks, > > > > --- Jayesh > > >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
