RE: synchronizing on the session object

"Hagai Sela \(TA\)" <[email protected]>
Newsgroups gmane.comp.voip.nist-sip
Message-ID <[email protected]>
Hi guys,
The scenario I described happens with REENTRANT_LISTENER set to true.

I think per-dialog sync won't help in this case, since I have two
dialogs, and two threads, each receive a request or response on one
dialog and later trying to send the request or response on the other
dialog.

Do you have any suggestions regarding my specific deadlock?

Hagai.

-----Original Message-----
From: M. Rangnathan [mailto:[email protected]] 
Sent: Monday, November 20, 2006 3:18 AM
To: Jeroen van Bemmel
Cc: Hagai Sela (TA); [email protected]
Subject: Re: [nist-sip] synchronizing on the session object

Jeroen van Bemmel wrote:

> Hagai,
>  
> It may work when you set 'gov.nist.javax.sip.REENTRANT_LISTENER' to 
> 'true'. If that is false (default) all callbacks to the application 
> will occur within the same, single thread each time. Blocking that 
> thread (e.g. by using 'synchronize(o)') will indeed result in deadlock
>  
> Regards,
> Jeroen
>  
> PS IMHO this is an omission in the JAIN specs, the threading 
> architecture is basically not specified. The property above is NIST RI

> specific, the solution is not portable across vendors



I agree with the observation above. Things should be clearly spelled out
in the spec. We should fix this oversight next time.

Currently, two synchroization models are supported : Global or per
Transaction. The Global scheme (i.e. REENTRANT_LISTENER = false) is the
default and its behavior is as described by Jeroen above. When you set
REENTRANT_LISTENER = true . one and only one event is outstanding in the
listener per transaction at any given time. That is the listener cannot
concurrently process two events for the same transaction at any instant
of time. I think this is the minimum level of sychronization that is
acceptable.  In the implementation, there is a per transaction Semaphore
that takes care of this. Do we need a per-dialog synchronization model
as well ?


>     ----- Original Message -----
>     *From:* Hagai Sela (TA) <mailto:[email protected]>
>     *To:* Hagai Sela (TA) <mailto:[email protected]> ;
>     [email protected] <mailto:[email protected]>
>     *Sent:* Sunday, November 19, 2006 2:01 PM
>     *Subject:* RE: [nist-sip] synchronizing on the session object
>
>     oops, I had a mistake. Item 7 should be:
>      
>     7. thread 1 tries to send cancel in dialog B.
>     getNewClientTransaction is called, and findCancelTransaction finds
>     dialog B's invite transaction. when getDialog() is called on that
>     transaction we have a deadlock.
>      
>
>
------------------------------------------------------------------------
>     *From:* [email protected]
>     <mailto:[email protected]>
>     [mailto:[email protected]] *On Behalf Of *Hagai Sela
(TA)
>     *Sent:* Sunday, November 19, 2006 2:39 PM
>     *To:* [email protected]
>     *Subject:* [nist-sip] synchronizing on the session object
>
>     Hi,
>     I have a nist-sip based B2BUA. I want to be able to synchronize on
>     a session object to serialize request handling on both dialogs on
>     the B2BUA, so if I am handling something on one dialog and a
>     request on the other dialog comes along it will wait.
>     This causes deadlocks, since the stack is synchronized on
>     transaction objects before calling my listener. for example:
>      
>     1. The stack receives an INVITE on dialog A, and forwards it on
>     dialog B.
>     2. CANCEL is received on dialog A in thread 1.
>     3. My listener is called, and is synchronized on the session
>     object (thread 1)
>     4. a negative response is received on dialog B in thread 2.
>     5. The stack is synchronized on B's INVITE client transaction in
>     thread 2.
>     6. My listener is called again, tries to synchronize on the
>     session object, and is blocked (thread 2).
>     7. thread 1 tries to send cancel in dialog B.
>     getNewClientTransaction is called, and findCancelTransaction finds
>     dialog A's invite transaction. when getDialog() is called on that
>     transaction we have a deadlock.
>      
>     Should I not synchronize on any of my objects in the stack
callbacks?
>      
>     Hagai.
>      
>
>
------------------------------------------------------------------------
>     _______________________________________________
>     nist-sip mailing list
>     [email protected]
>     http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>
>-----------------------------------------------------------------------
>-
>
>_______________________________________________
>nist-sip mailing list
>[email protected]
>http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>  
>


--
M. Ranganathan 

Advanced Networking Technologies Division, National Institute of
Standards and Technology (NIST), 100 Bureau Drive, Stop 8920,
Gaithersburg, MD 20899. 
tel:301 975 3664 , fax:301 590 0932 http://w3.antd.nist.gov/ Advanced
Networking Technologies For the People!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.