Bugs item #2948561, was opened at 2010-02-09 17:38
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2948561&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: 1.6.x
>Status: Closed
Resolution: Invalid
Priority: 1
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: deadlock on pua presentity lock
Initial Comment:
Hi,
when sending the PUBLISH messages to self, using:
modparam("pua_dialoginfo", "presence_server", "sip:a.b.c.d:5060") # send
PUBLISH messages to self
I get a deadlock of the entire opensips daemon.
If I send the messages to somewhere else, the deadlock does not occur.
If I release the locks as per the attached patch, the deadlock doesn't occur
either.
But according to the comments in the code, the lock is not meant to be freed
just yet. So I'm not sure what my patch breaks instead. (I'm not even sure I'm
supposed to publish to self, but it seems like it, as I want to generate
notifies based on the state changes found in the publish.)
I'm running 1.6-svn (r6568)
Regards,
Walter Doekes
OSSO B.V.
--
>Comment By: Anca Vamanu (anca_vamanu)
Date: 2010-03-02 11:58
Message:
Thanks you, Walter. I updated the documentation.
Regards,
Anca
--
Comment By: Walter Doekes (wdoekes)
Date: 2010-03-01 14:44
Message:
Okay, thank you for that information.
Isn't this something that should be documented? Or is it already and have
I simply missed it?
Regards,
Walter
--
Comment By: Anca Vamanu (anca_vamanu)
Date: 2010-02-24 10:15
Message:
Hi Walter,
The reason you get a deadlock is exactly that you use only one child. The
process might get blocked while trying to send a new Publish request and
there is no one to handle the reply for the previous one and release the
lock. So, it is compulsory to have more children when using pua module.
Regards,
Anca
--
Comment By: Walter Doekes (wdoekes)
Date: 2010-02-24 08:59
Message:
Furthermore, I can add that I used children=1.
(Having children as 1 also led me to believe that setting $var()s in
startup_route could be used as process-wide constants, which they cannot.
This should clear up some more of the odd issues I was having. How would
you feel about a process_startup_route? I cannot believe I'm the only one
who likes constants at the top of the file.)
--
Comment By: Walter Doekes (wdoekes)
Date: 2010-02-12 10:11
Message:
Hi Anca,
Thanks for your quick reply.
I've tried to reduce/declutter my config file to make it easily
reproducable, but during this reduction the problem goes away. I can hardly
give you the full config file as it's a bit of a complex hack, and
incomplete at that ;)
Yes, what I want to do is implement BLF on OpenSIPS. To do this, I do
basically this:
route {
if (uri == myself) {
if ($si == "e.f.g.h") { # my IP
if (method == "PUBLISH") {
handle_publish("sip:mys...@myself.myself");
exit;
}
}
if (method == "SUBSCRIBE") {
handle_subscribe();
exit;
}
if (method == "INVITE") {
dialoginfo_set();
record_route();
}
if ($si == "a.b.c.d") {
$var(local) = "sip:" + $(hdr(X-PIDstAccount)[-1]) + "@anydomain";
lookup("opensips_location", "", "$var(local)");
} else {
$rd = "a.b.c.d";
}
t_relay();
}
}
(Add a bit of nat handling, registration handling and transaction
handling.)
Modules loaded are:
loadmodule "xlog.so"# logging (xlog)
loadmodule "sl.so" # stateless functions (sl_*)
loadmodule "tm.so" # t_*: transactions in memory
loadmodule "signaling.so" # send reply according to state
loadmodule "rr.so" # record route
loadmodule "nathelper.so" # fix_nated_*()
loadmodule "textops.so" # append_hf
loadmodule "uri.so" # has_totag
loadmodule "db_mysql.so"# mysql
loadmodule "auth.so"# digest auth
loadmodule "auth_db.so" # digest auth
loadmodule "group.so" # groups (for acls)
loadmodule "permissions.so" # permissions (provide acls together with
groups)
loadmodule "usrloc.so" # user location
loadmodule "registrar.so" # lookup/save/registered
loadmodule "dialog.so" # ...
loadmodule "presence.so"# handle SUBSCRIBE events
loadmodule "presence_dialoginfo.so" # handle SUBSCRIBE events for
dialoginfo
loadmodule "presence_xml.so"# handle SUBSC
