[OpenSIPS-Users] Users Digest, Vol 30, Issue 12
jayesh.voip at gmail.com
Fri Jan 7 08:11:19 CET 2011
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 !!
> 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users