I have terminateOtherLeg on all error codes in onSipReply. I have
reduced the number of threads that are leaked by adding code to check if
there should be an extra leg in process. As I was calling
terminateOtherLeg twice on error conditions.
I still have a couple of useless threads, but the number is dramatically
reduced. (Or it could be the reason the thread is leaking, hasn't
happened much over the last three days.) I am continuing to watch and
tweak.
Peter
On Tue, 2009-05-19 at 11:34 +0200, Stefan Sayer wrote:
> Hello,
>
> o Peter Loeppky [05/13/09 17:21]:
> > I have a B2B application running. Every now and again, I am having an
> > issue with some threads got getting destroyed. From what I can tell, it
> > appears that it is the second legs that stays open.
>
> this happens if in your application you don't call setStopped() for all
> possible cases.
>
> Usually with b2b apps that is failed calls on the second leg. IIRC you
> need to check whether the dialog's status changes from Pending to
> Disconnected in onSipReply, or, in the caller leg, you need to call
> terminateOtherLeg(). It's not really intuitive; do you think we should
> introduce onFailedCall event handler?
>
> Stefan
>
> >
> >>From what I see the
> >
> > AmSession::sess_stopped = False;
> > AmSession::detached = True;
> > AmSipDialog::status = Disconnected/0;
> >
> > void AmSession::run()
> > {
> >
> > ...
> > while (!sess_stopped.get() ||
> > (dlg.getStatus() == AmSipDialog::Disconnecting)// ||
> > // (dlg.getUACTransPending())
> > ){
> >
> > --> waitForEvent();
> > processEvents();
> >
> > DBG("%s dlg.getUACTransPending() = %i\n",
> > dlg.callid.c_str(),dlg.getUACTransPending());
> > }
> > ...
> > }
> >
> > And is stuck waiting for events(). Any ideas?
> >
> > Peter
> >
> > _______________________________________________
> > Sems mailing list
> > [email protected]
> > http://lists.iptel.org/mailman/listinfo/sems
>
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
