[OpenSIPS-Users] Users Digest, Vol 30, Issue 12

[Jayesh Nambiar]

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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110107/1b5c3880/attachment.htm>