[OpenSIPS-Devel] [ opensips-Patches-3042432 ] [pua] add a "publish" queue to avoid deadlock

[SourceForge.net]

Patches item #3042432, was opened at 2010-08-10 12:55
Message generated for change (Tracker Item Submitted) made by csollet
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3042432&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christophe Sollet (csollet)
Assigned to: Nobody/Anonymous (nobody)
Summary: [pua] add a "publish" queue to avoid deadlock

Initial Comment:
Hi,

I'm facing a lot of deadlock situation with pua and pua_usrloc modules as pua maintain a lock on presentity and hope a tm callback will unlock it.
Sadly, the timer process can easily deadlock itself when the reply never get in . For example : 

TimerProcess : pua::HashT_clean --> update_pua  : lock presentity A and init a new transaction
TimerProcess : usrloc --> pua_usrloc --> ul_publish --> send_publish : block trying to lock presentity A

If the new transaction never get a reply, the tm timer will never get a chance to generate a local 408 as the timer process is already busy to get the lock.

I've tried to solve this issue by running the hashT_clean & db_update on separate process without more success. I suppose it may work only by running every timer that have callback to send_publish() on a distinct process.

The attached patch try to solve this issue by adding a publish queue to presentity : if a publish is already waiting for a reply, the requested one is put on hold and will be sent later by the tm callback. This allow update_pua() and send_publish() to let presentity unlocked will tm wait for a reply.

I'm not sure to understand all the side effect this change can lead to. Not even that is the right way to do it. At least, it solved the deadlock issue...

Regards,
Christophe.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3042432&group_id=232389