Hi Laurent, are you sure that you updated your code (SVN:trunk) up to version 1001? In the logs, i cannot find the new timer L, which is the major piece of the fix. Could please check if you can find this timer in your code?
grep -r STIMER_L * shall return something in the sipctrl plug-in. -Raphael. Laurent Schweizer wrote: > I do the test with SW_prepaid_sip application, not with my application. > > I will do the same test with my application. > > Laurent > > > -----Original Message----- > From: Stefan Sayer [mailto:[EMAIL PROTECTED] > Sent: mardi 3 juin 2008 11:55 > To: Laurent Schweizer > Cc: [EMAIL PROTECTED]; Raphael Coeffic > Subject: Re: [Semsdev] 2 problems with sems > > > > o Laurent Schweizer [06/03/08 10:22]: > >> Hello, >> >> Attached log of my last test with last version. >> >> I wait after the last call before killing sems . >> >> Laurent >> >> > something must be wrong with your application logic: you still have 74 > sessions running. check that you end all sessions with setStopped(). > > Stefan > > >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Sayer >> Sent: lundi 2 juin 2008 13:31 >> To: Raphael Coeffic >> Cc: [EMAIL PROTECTED] >> Subject: Re: [Semsdev] 2 problems with sems >> >> >> >> o Raphael Coeffic [06/02/08 12:26]: >> >>>>> It looks like you have a lot (405) of thrashed sessions still in >>>>> >> memory. >> >>>> where do you see them? >>>> >>>> >>> In the memory traces. >>> >> ah ;) >> >> but how is the transactions on sip stack level linked to the session >> objects other than the transaction id? i mean, how will freeing the >> session affect sip stack's memory? >> >> i see the count 405 only in loss record 43, 47 and 106, and they are >> > all > >> sip transaction related and not on dialog/session level. >> >> Stefan >> >> >>> -Raphael. >>> > > _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
