[reSIProcate] Unable to shutdown DUM during retransmission ofMESSAGE requests

[Scott Godin]

I've committed a fix for this.  The DialogSet and Usage should now be
immediately destroyed if you call end() on ClientPagerMessage usage.  

The fix involved rewriting the logic used to keep DialogSet's around
when Dialogs are destroyed during redirect handling.  This new solution
should be much cleaner.  

Thanks,

Scott

-----Original Message-----
From: Fischl jason [mailto:jason.fischl at gmail.com] 
Sent: Wednesday, August 10, 2005 12:53 PM
To: Scott Godin
Cc: Dmitry Semyonov; resiprocate-devel at list.sipfoundry.org
Subject: Re: [reSIProcate] Unable to shutdown DUM during retransmission
ofMESSAGE requests

On 8/10/05, Scott Godin <slgodin at icescape.com> wrote:
> Ah, yes - I see the problem.  Calling end() while retransmissioning
> causes the following to occur:
> 
> Calling end() will cause ClientPagerMessage to be destructed.  The
> BaseUsage base class will end up calling DialogSet::possiblyDie().
The
> DialogSet::possiblyDie() method checks the state of the DialogSet and
> will not destroy itself if the DialogSet state is Initial.  Thus the
> DialogSet never get's deleted - and Dum will not shutdown.
> 
> Conversely, if you call end() in onFailure() the DialogSet state is
> changed to Established and possiblyDie ends up allowing the DialogSet
to
> be deleted.  Shutdown works fine.
> 
> I'll have talk to the other developers on how to best fix this.
Should
> the DialogSet stay around until the final response?  If so, we need to
> handle self deletion if there are no usages or Dialogs existing on the
> DialogSet.

What would be the reason for keeping the usage around after the
application calls end? Shouldn't we just delete the usage right then
and there?

I think we should handle this self-deletion case when deleting
DialogSet with an extra check (as you suggest)

> 
> Thanks,
> 
> Scott
> 
> -----Original Message-----
> From: Dmitry Semyonov [mailto:dsemyonov at dins.ru]
> Sent: Wednesday, August 10, 2005 6:37 AM
> To: Scott Godin
> Cc: resiprocate-devel at list.sipfoundry.org
> Subject: RE: [reSIProcate] Unable to shutdown DUM during
retransmission
> ofMESSAGE requests
> 
> Scott,
> 
> If I call end() inside onFailure() DUM shuts down indeed. But when
> end() is called during MESSAGE retransmissions, the retransmissions
> continue, (they even continue after shutdown()) and after that I
> can see in the trace that there is no "Destroying usage" line for
> MESSAGE DialogSet after retransmissions timeout.
> 
> See attached logs with two cases described above.
> 
> 
> On Tue, 9 Aug 2005, Scott Godin wrote:
> 
> > I can understand why it would not shutdown if you don't call end() -
> > since nothing would destroy the usage.
> >
> > But if you call end() before shutdown, then it SHOULD shutdown OK.
To
> > figure this one out - you will likely need to walk through a trace
to
> > find out what usages/handles are still around.
> >
> > Scott
> >
> > -----Original Message-----
> > From: resiprocate-devel-bounces at list.sipfoundry.org
> > [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
> > Dmitry Semyonov
> > Sent: Tuesday, August 09, 2005 1:00 PM
> > To: resiprocate-devel at list.sipfoundry.org
> > Subject: [reSIProcate] Unable to shutdown DUM during retransmission
> > ofMESSAGE requests
> >
> > Hello.
> >
> > Consider the following scenario.
> >  * Send MESSAGE to nowhere.
> >  * DUM starts the series of retransmissions.
> >  * Shutdown DUM before onFailure() is called due to retransmissions
> > timeout.
> >
> > In this case DUM never exits.
> >
> > I even tried to call ClientPagerMsgHandle->end() before shutting DUM
> > down with no luck. (I.e. I was not able to force transaction end.)
> 
> --
> ...Bye..Dmitry.
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.sipfoundry.org
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>