RE: Memory leak in nist implementation
Francisco Javier Tellez Vaquero <[email protected]> Mon, 30 Jun 2008 21:10:09 +0200
| Newsgroups | gmane.comp.voip.nist-sip |
|---|---|
| Message-ID | <[email protected]> |
--===============8804340808769713160== Content-Type: multipart/alternative; boundary="_34f34ca3-b1c5-4472-89bd-65ceb3161cf8_" --_34f34ca3-b1c5-4472-89bd-65ceb3161cf8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Jeroen, it's the solution we have implemented at UAS side. But the problem is at th= e other side, you send a BYE request but you don't receive response. We have tried executing 'terminate()' method at transaction level, 'delete(= )' at dialog level, but without any result. We see similar problem when ACK is not received. Best Regards, Fran. > Date: Mon, 30 Jun 2008 21:00:57 +0200 > From: [email protected] > To: [email protected] > CC: [email protected]; [email protected] > Subject: Re: [nist-sip] Memory leak in nist implementation >=20 > Francisco, >=20 > A B2BUA application connects 2 Dialog objects together, one on the "UAS"= =20 > side (receiving a request) and one on the "UAC" side (forwarding the=20 > request) > Could it be that you are referring to the "UAS" Dialog that is never=20 > destroyed? >=20 > From that Dialog's perspective, your application received the BYE but=20 > never sent a 200 OK. That's different from sending out a BYE onto the=20 > network, and not receiving a 200 OK. >=20 > The proper solution would be to implement logic in the BYE=20 > ClientTransaction timeout handler, to still send a 200 OK for the BYE on= =20 > the "UAS" side. Alternatively, you can always immediately send 200 OK=20 > when you receive a BYE, and generate a BYE for the second Dialog at the=20 > same time. >=20 > Regards, > Jeroen >=20 > Francisco Javier Tellez Vaquero wrote: > > Hi again, > > we have an application running as a B2BUA. > > > > If we receive a BYE from an end point, we send the BYE to the other=20 > > point. When we receive 200 response, we re-transmit it. > > > > We see sometimes this response is lost (because of network problems,=20 > > because of terminal, ...). The question is the dialog is never=20 > > destroyed until application is re-started. We have wait for garbage=20 > > collection (application is running for days). > > > > Regards. > > > > > > > Date: Mon, 30 Jun 2008 14:39:30 -0400 > > > From: [email protected] > > > To: [email protected] > > > Subject: Re: [nist-sip] Memory leak in nist implementation > > > CC: [email protected] > > > > > > When the tx times out delete the dialog and then you have to wait for > > > the garbage collection to run before you check for leak. > > > > > > Ranga. > > > > > > On Mon, Jun 30, 2008 at 2:32 PM, Francisco Javier Tellez Vaquero > > > <[email protected]> wrote: > > > > Hi Ranga, > > > > I agree the example case is a listener bug, but think the opposite= =20 > > case: > > > > > > > > - You send a BYE request but no response is received. > > > > > > > > You have no control about this point, so the idea is trying to=20 > > close the > > > > dialog anyway. > > > > > > > > BR. > > > > > > > > > > > >> Date: Mon, 30 Jun 2008 14:09:05 -0400 > > > >> From: [email protected] > > > >> To: [email protected] > > > >> Subject: Re: [nist-sip] Memory leak in nist implementation > > > >> CC: [email protected] > > > >> > > > >> On Mon, Jun 30, 2008 at 1:55 PM, Francisco Javier Tellez Vaquero > > > >> <[email protected]> wrote: > > > >> > Hi all, > > > >> > I see sometimes not all stack objects are destroyed. > > > >> > > > > >> > For example, if you receive BYE request but no 200 response is=20 > > sent, > > > >> > dialog > > > >> > is never closed. There're a lot of different cases (ACK's lost,= =20 > > ...). > > > >> > > > >> Not sending a 200 OK to a BYE is an application bug. Please fix th= at. > > > >> > > > >> Please post a specific test case (without listener bugs) and I=20 > > can look > > > >> into it. > > > >> > > > >> Ranga > > > >> > > > >> > > > > >> > I have tried to free memory executing 'terminate()' and/or=20 > > 'delete()' > > > >> > methods in both transaction and dialog objects but without any=20 > > result. > > > >> > > > > >> > Is there any way to force to free these objects (timers, dialogs= , > > > >> > transactions, ...) ? > > > >> > > > > >> > Regards. > > > >> > > > > >> > > > > >> > > > > >> > ________________________________ > > > >> > Tecnolog=EDa, moda, motor, viajes,.suscr=EDbete a nuestros=20 > > boletines para > > > >> > estar > > > >> > siempre a la =FAltima MSN Newsletters > > > >> > _______________________________________________ > > > >> > nist-sip mailing list > > > >> > [email protected] > > > >> > http://www-x.antd.nist.gov/mailman/listinfo/nist-sip > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> M. Ranganathan > > > > > > > > ________________________________ > > > > Sigue los principales acontecimientos deportivos en directo. MSN Mo= tor > > > > > > > > > > > > -- > > > M. Ranganathan > > > > -----------------------------------------------------------------------= - > > Sigue al minuto las principales noticias de tu ciudad MSN Deportes=20 > > <http://deportes.es.msn.com/> > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > nist-sip mailing list > > [email protected] > > http://www-x.antd.nist.gov/mailman/listinfo/nist-sip > > =20 _________________________________________________________________ MSN Noticias http://noticias.msn.es/comunidad.aspx= --_34f34ca3-b1c5-4472-89bd-65ceb3161cf8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style> .hmmessage P { margin:0px; padding:0px } body.hmmessage { FONT-SIZE: 10pt; FONT-FAMILY:Tahoma } </style> </head> <body class=3D'hmmessage'> Hello Jeroen,<br>it's the solution we have implemented at UAS side. But the= problem is at the other side, you send a BYE request but you don't receive= response.<br><br>We have tried executing 'terminate()' method at transacti= on level, 'delete()' at dialog level, but without any result.<br><br>We see= similar problem when ACK is not received.<br><br>Best Regards,<br>Fran.<br= ><br><br>> Date: Mon, 30 Jun 2008 21:00:57 +0200<br>> From: jbemmel@z= onnet.nl<br>> To: [email protected]<br>> CC: [email protected]= m; [email protected]<br>> Subject: Re: [nist-sip] Memory leak in ni= st implementation<br>> <br>> Francisco,<br>> <br>> A B2BUA appl= ication connects 2 Dialog objects together, one on the "UAS" <br>> side = (receiving a request) and one on the "UAC" side (forwarding the <br>> re= quest)<br>> Could it be that you are referring to the "UAS" Dialog that = is never <br>> destroyed?<br>> <br>> From that Dialog's perspecti= ve, your application received the BYE but <br>> never sent a 200 OK. Tha= t's different from sending out a BYE onto the <br>> network, and not rec= eiving a 200 OK.<br>> <br>> The proper solution would be to implement= logic in the BYE <br>> ClientTransaction timeout handler, to still send= a 200 OK for the BYE on <br>> the "UAS" side. Alternatively, you can al= ways immediately send 200 OK <br>> when you receive a BYE, and generate = a BYE for the second Dialog at the <br>> same time.<br>> <br>> Reg= ards,<br>> Jeroen<br>> <br>> Francisco Javier Tellez Vaquero wrote= :<br>> > Hi again,<br>> > we have an application running as a B= 2BUA.<br>> ><br>> > If we receive a BYE from an end point, we s= end the BYE to the other <br>> > point. When we receive 200 response,= we re-transmit it.<br>> ><br>> > We see sometimes this respons= e is lost (because of network problems, <br>> > because of terminal, = ...). The question is the dialog is never <br>> > destroyed until app= lication is re-started. We have wait for garbage <br>> > collection (= application is running for days).<br>> ><br>> > Regards.<br>>= ; ><br>> ><br>> > > Date: Mon, 30 Jun 2008 14:39:30 -0400= <br>> > > From: [email protected]<br>> > > To: fjavier_tel= [email protected]<br>> > > Subject: Re: [nist-sip] Memory leak in ni= st implementation<br>> > > CC: [email protected]<br>> >= ><br>> > > When the tx times out delete the dialog and then yo= u have to wait for<br>> > > the garbage collection to run before y= ou check for leak.<br>> > ><br>> > > Ranga.<br>> > = ><br>> > > On Mon, Jun 30, 2008 at 2:32 PM, Francisco Javier Te= llez Vaquero<br>> > > <[email protected]> wrote:<br= >> > > > Hi Ranga,<br>> > > > I agree the example c= ase is a listener bug, but think the opposite <br>> > case:<br>> &= gt; > ><br>> > > > - You send a BYE request but no respon= se is received.<br>> > > ><br>> > > > You have no c= ontrol about this point, so the idea is trying to <br>> > close the<b= r>> > > > dialog anyway.<br>> > > ><br>> > &g= t; > BR.<br>> > > ><br>> > > ><br>> > >= >> Date: Mon, 30 Jun 2008 14:09:05 -0400<br>> > > >> = From: [email protected]<br>> > > >> To: fjavier_tellez@hotmai= l.com<br>> > > >> Subject: Re: [nist-sip] Memory leak in nis= t implementation<br>> > > >> CC: [email protected]<br>&= gt; > > >><br>> > > >> On Mon, Jun 30, 2008 at 1= :55 PM, Francisco Javier Tellez Vaquero<br>> > > >> <fjav= [email protected]> wrote:<br>> > > >> > Hi all,<b= r>> > > >> > I see sometimes not all stack objects are de= stroyed.<br>> > > >> ><br>> > > >> > Fo= r example, if you receive BYE request but no 200 response is <br>> > = sent,<br>> > > >> > dialog<br>> > > >> >= ; is never closed. There're a lot of different cases (ACK's lost, <br>> = > ...).<br>> > > >><br>> > > >> Not sendin= g a 200 OK to a BYE is an application bug. Please fix that.<br>> > &g= t; >><br>> > > >> Please post a specific test case (wi= thout listener bugs) and I <br>> > can look<br>> > > >>= ; into it.<br>> > > >><br>> > > >> Ranga<br>&= gt; > > >><br>> > > >> ><br>> > > &g= t;> > I have tried to free memory executing 'terminate()' and/or <br>= > > 'delete()'<br>> > > >> > methods in both transa= ction and dialog objects but without any <br>> > result.<br>> >= > >> ><br>> > > >> > Is there any way to for= ce to free these objects (timers, dialogs,<br>> > > >> > = transactions, ...) ?<br>> > > >> ><br>> > > >= > > Regards.<br>> > > >> ><br>> > > >&g= t; ><br>> > > >> ><br>> > > >> > ___= _____________________________<br>> > > >> > Tecnolog=EDa,= moda, motor, viajes,.suscr=EDbete a nuestros <br>> > boletines para<= br>> > > >> > estar<br>> > > >> > siemp= re a la =FAltima MSN Newsletters<br>> > > >> > __________= _____________________________________<br>> > > >> > nist-= sip mailing list<br>> > > >> > [email protected]<br>= > > > >> > http://www-x.antd.nist.gov/mailman/listinfo/ni= st-sip<br>> > > >> ><br>> > > >> ><br>&= gt; > > >><br>> > > >><br>> > > >>= ;<br>> > > >> --<br>> > > >> M. Ranganathan<b= r>> > > ><br>> > > > ______________________________= __<br>> > > > Sigue los principales acontecimientos deportivos = en directo. MSN Motor<br>> > ><br>> > ><br>> > >= <br>> > > --<br>> > > M. Ranganathan<br>> ><br>>= > ---------------------------------------------------------------------= ---<br>> > Sigue al minuto las principales noticias de tu ciudad MSN = Deportes <br>> > <http://deportes.es.msn.com/><br>> > ---= ---------------------------------------------------------------------<br>&g= t; ><br>> > _______________________________________________<br>>= ; > nist-sip mailing list<br>> > [email protected]<br>> &g= t; http://www-x.antd.nist.gov/mailman/listinfo/nist-sip<br>> > <br>= <br /><hr />Tecnolog=EDa, moda, motor, viajes,.suscr=EDbete a nuestros bole= tines para estar siempre a la =FAltima <a href=3D'http://newsletters.msn.co= m/hm/maintenanceeses.asp?L=3DES&C=3DES&P=3DWCMaintenance&Brand=3DWL&RU=3Dht= tp%3a%2f%2fmail.live.com' target=3D'_new'>MSN Newsletters</a></body> </html>= --_34f34ca3-b1c5-4472-89bd-65ceb3161cf8_-- --===============8804340808769713160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ nist-sip mailing list [email protected] http://www-x.antd.nist.gov/mailman/listinfo/nist-sip --===============8804340808769713160==--