Yes – queuing a DumCommand that calls end() will mean that it is
called from the dum thread – this is safe.
From: Kovar, William
(Bill) [mailto:bkovar@xxxxxxxxx]
Sent: Thursday, January 18, 2007 4:43 PM
To: Scott Godin
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Session destroyed while in OnTerminated(..)
see below..
Bill
Kovar
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Thursday, January 18, 2007 4:26 PM
To: Kovar, William (Bill)
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Session destroyed while in OnTerminated(..)
Bill,
It the threading model was valid,
[Kovar, William (Bill)] I AM assuming that my threading
model is invalid, i.e. calling session->end() from an App thread is BAD!!,
and I'm trying to best understand how to fix it. My question below still
stands. Will DumCommand fix the timing problem?
then Dum should not be able to process the 200 response
while you are in your onTerminated callback. The process loop should be
blocked. [Kovar, William (Bill)] Right!! But it's not given my
scenario.
How do you ensure that messages such as BYE and their responses
are routed to the same dum thread that created the dialog by using the
message filter rules?[Kovar, William (Bill)] Since I only run a small number of
UAs ( 1 B2B for almost all my devices, and separate UAs for special
devices) I register their URI in a UserList similar to
resip::MessageFilterRule::SchemeList and then added code in MessageFilterRule
to handle the new type of List. Since the MessageFilterRule is at the Stack
level, I continually add new URIs when needed and the TU layer routes the msg
to the correct DUM.
Scott
From: Kovar, William
(Bill) [mailto:bkovar@xxxxxxxxx]
Sent: Thursday, January 18, 2007 4:09 PM
To: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Session destroyed while in OnTerminated(..)
Scott,
You may have mis-understood me. I have an app thread that
controls/monitors one of N UAs, each running on their own DumThread but sharing
a single StackThread. Use of a single Stack thread across multiple Dums is
accomplished by adding user based switching in MessageFilterRule. Works quite
nicely for phone numbers, actually!!
In no situation does one Dum thread (UA) ever make a call on
another Dum thread. I don't do that kind of thread hopping.
What I am doing, which I believe is solvable with DumCommand, is
this: At the App thread, when I decide which UA to control, I directly call
session->end() from the App thread causing the problem I described, namely,
if OnTerminated() runs too long, the 200 OK response to the BYE blows away the
session/Dialog/etc.
So my question is: Will the use of DumCommand in this instance,
from my App thread, directed at a specific Dum thread, fix the sequence
problem??
Bill
Kovar
bkovar@xxxxxxxxx
Avaya,
Inc.
(732)
852-2609
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Thursday, January 18, 2007 3:56 PM
To: Kovar, William (Bill); resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Session destroyed while in OnTerminated(..)
It is not legal to have multiple dum threads. All calls to
dum->process and the dum api’s must be run from the same thread, or must be
protected.
http://www.resiprocate.org/DUM_Threading
From: Kovar, William
(Bill) [mailto:bkovar@xxxxxxxxx]
Sent: Thursday, January 18, 2007 3:20 PM
To: Scott Godin; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Session destroyed while in OnTerminated(..)
I run 2 dums, 1 SipStack in my B2B, each using DumThread (2) and
the same StackThread(1).
So my calling session->end() from outside of the Dum thread is
causing this sequencing problem??
And posting the session->end() using DumCommand will get
around this sequencing problem??
Bill
Kovar
bkovar@xxxxxxxxx
Avaya,
Inc.
(732)
852-2609
From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
Sent: Thursday, January 18, 2007 2:17 PM
To: Kovar, William (Bill); resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Session destroyed while in OnTerminated(..)
It seems that you may have multiple dum threads running.
Dum should only be running in one thread. With dum running in one thread
– nothing else in dum happens until you return from the onTerminated callback.
The 15ms delay you are seeing is likely due to some problem in
your process loop.
Scott
From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx]
On Behalf Of Kovar, William (Bill)
Sent: Wednesday, January 17, 2007 6:08 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Session destroyed while in OnTerminated(..)
I'm
sure this is not new information but I am wondering what, if anything
could/will be done to the following problem regarding OnTerminated() callback.
When
one sends an BYE with InviteSessionHandle->end() the following happens:
1.
The BYE msg is built and put on the Fifo ready to be sent on the wire
2.
the session is transitioned to IsTerminating()
3.
The onTerminated() callback is fired.
If
system load causes a slowdown, it quite easy to be manipulating the session in
OnTerminated() and the AppDialog, AppdialogSet and InviteSession all get
destroyed before exiting the callback. This happens when the BYE gets a 200 OK
answer and the session is torn down.
It
seems that there is a window of ~15ms before the BYE msg is sent out. What's
controlling this time?
Any
suggestions how to get around this issue or if the session will be kept around
longer than the receipt of the 200 OK on the BYE. Any forseeable changes to
DUM?
Bill
Kovar
bkovar@xxxxxxxxx
Avaya,
Inc.
(732)
852-2609
|