Module: sip-router
Branch: master
Commit: 126131202c76337103d67402940d0a2d6438e3e8
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=1261312…
Author: Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>
Committer: Peter Dunkley <peter.dunkley(a)crocodile-rcs.com>
Date: Sun May 13 01:17:56 2012 +0100
modules_k/pua: Use non-pooled connections in db only mode (where supported)
- This helps with databases (such as PostgreSQL, which is the only one that
currently supports specifying non-pooled connections) that create a server
process per client connection.
---
modules_k/pua/pua.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/modules_k/pua/pua.c b/modules_k/pua/pua.c
index 5d11066..b72f9e1 100644
--- a/modules_k/pua/pua.c
+++ b/modules_k/pua/pua.c
@@ -296,7 +296,11 @@ static int child_init(int rank)
LM_CRIT("database not bound\n");
return -1;
}
- pua_db = pua_dbf.init(&db_url);
+ /* In DB only mode do not pool the connections where possible. */
+ if (dbmode == PUA_DB_ONLY && pua_dbf.init2)
+ pua_db = pua_dbf.init2(&db_url, DB_POOLING_NONE);
+ else
+ pua_db = pua_dbf.init(&db_url);
if (!pua_db)
{
LM_ERR("Child %d: connecting to database failed\n", rank);
@@ -321,7 +325,11 @@ static int mi_child_init(void)
LM_CRIT("database not bound\n");
return -1;
}
- pua_db = pua_dbf.init(&db_url);
+ /* In DB only mode do not pool the connections where possible. */
+ if (dbmode == PUA_DB_ONLY && pua_dbf.init2)
+ pua_db = pua_dbf.init2(&db_url, DB_POOLING_NONE);
+ else
+ pua_db = pua_dbf.init(&db_url);
if (!pua_db)
{
LM_ERR("connecting to database failed\n");
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Charles Chance (sipcentric)
Attached to Project - sip-router
Summary - domain_attrs_table parameter not defined
Task Type - Bug Report
Category - Modules kamailio
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - The parameter "domain_attrs_table" is not exported by domain_mod.c, therefore Kamailio fails to start if parameter is defined in config.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=232
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
Vicente Hernando has taken ownership of the following task:
FS#231 - ndb_redis redis_free function
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=231
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Vicente Hernando (vicente)
Attached to Project - sip-router
Summary - ndb_redis redis_free function
Task Type - Improvement
Category - Module
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - redis_free function removes a redis reply from memory.
Only needed if a user performs a lot of different redis_cmd requests with different replyid.
The first patch frees memory cleanly when ndb_redis module is destroyed.
Second patch creates redis_free function and adds documentation.
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=231
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Bayan Towfiq (btowfiq)
Attached to Project - sip-router
Summary - $sndto(ip) gives ip:port instead of just IP
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Medium
Priority - Normal
Reported Version - 3.1
Due in Version - Undecided
Due Date - Undecided
Details - In onsend_route $sndto(ip) gives IP:port i.e. "10.1.1.10:5060" instead of just the IP address.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=230
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Pawel Sternal (Sternik)
Attached to Project - sip-router
Summary - ACK not in transaction when t_relay or t_check_trans
Task Type - Bug Report
Category - Core
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Low
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - Hi. We have noticed in currently installed kamailio 3.2.2 have problem with ACK. In kamailio 1.5.2 there are no problem with it. When kamailio received and forward 200ok, ACK on that response is not in transaction. ACK after that is forwarding statelessly - header Record-Route is added to the package.
I'm looking at the diff between src of t_lookup.c with this "problem", and only I'm found that in 3.2.2, this ACK is in "2 - full match to a proxied transaction" when function "ack_matching" is call.
Below two output of this same connection, after trying t_relay(). Also when I'm trying to "t_check_trans". ACK is not matched to 200ok.
This is kamailio 1.5.2 log output
{code}
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:tm:t_newtran: transaction on entrance=0xffffffff
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:core:parse_headers: flags=ffffffffffffffff
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:core:parse_headers: flags=78
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:tm:t_lookup_request: start searching: hash=63132, isACK=1
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:core:parse_headers: flags=38
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:tm:t_lookup_request: RFC3261 ACK matched
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:tm:t_lookup_request: REF_UNSAFE: after is 1
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:tm:t_lookup_request: e2e proxy ACK found
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:tm:t_newtran: building branch for end2end ACK
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:tm:t_relay_to: forwarding ACK
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:core:mk_proxy: doing DNS lookup...
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:core:forward_request: sending: ACK sip:NUM@IP_ADDR:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP IP_ADDR;branch=z9hG4bKc96f.0501e9d4.2 Via: SIP/2.0/UDP IP_ADDR:5061;received=127.0.0.1;branch=z9hG4bK363e1c74;rport=5061 From: "NUM" <sip:NUM@IP>;tag=as3f095bcb To: <sip:NUM@IP_ADDR>;tag=chfs37pbjs4ecadm.i Contact: <sip:NUM@IP:5061> Call-ID: 0d39b2602a306e84290f641218ae01f7@IP CSeq: 102 ACK User-Agent: Server Max-Forwards: 70 Remote-Party-ID: "NUM" <sip:NUM@IP>;privacy=off;screen=no Content-Length: 0 .
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:core:forward_request: orig. len=597, new_len=631, proto=1
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:tm:t_unref_cell: UNREF_UNSAFE: after is 0
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:core:destroy_avp_list: destroying list 0xb3381970
May 10 13:35:54 kamailio /usr/sbin/kamailio[5715]: DBG:core:receive_msg: cleaning up
{code}
This is kamailio 3.2.2 log output
{code}
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: tm [t_lookup.c:1379]: DEBUG: t_newtran: msg id=35377 , global msg id=35376 , T on entrance=0xffffffff
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: tm [t_lookup.c:527]: t_lookup_request: start searching: hash=4487, isACK=1
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: tm [t_lookup.c:485]: DEBUG: RFC3261 transaction matching failed
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: tm [t_lookup.c:709]: DEBUG: t_lookup_request: no transaction found
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: tm [t_funcs.c:315]: SER: forwarding ACK statelessly
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [msg_translator.c:204]: check_via_address(127.0.0.1, IP, 0)
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [forward.c:601]: Sending: ACK sip:NUM@IP:5060;transport=udp SIP/2.0 Record-Route: <sip:IP:5060;ftag=as50b3af68;lr> Via: SIP/2.0/UDP IP;branch=z9hG4bKcydzigwkX Via: SIP/2.0/UDP IP:5061;received=127.0.0.1;branch=z9hG4bK587eb61e;rport=5061 From: "NUM" <sip:NUM@IP>;tag=as50b3af68 To: <sip:NUM@IP>;tag=ovqdnmak77x4xa54.i Contact: <sip:NUM@IP:5061> Call-ID: 356753f079bf1d780728315859ffb2ac@IP CSeq: 102 ACK User-Agent: Server Max-Forwards: 70 Remote-Party-ID: "NUM" <sip:NUM@IP>;privacy=off;screen=no Content-Length: 0 .
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [forward.c:603]: orig. len=597, new_len=685, proto=1
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list 0xb2f15ca8
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [usr_avp.c:644]: DEBUG:destroy_avp_list: destroying list (nil)
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [xavp.c:365]: destroying xavp list (nil)
May 10 12:23:43 kamailio /usr/sbin/kamailio[23198]: DEBUG: <core> [receive.c:291]: receive_msg: cleaning up
{code}
Maybe this not a bug, but why in kamailio 1.5.2 it work? :-)
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=229
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hi,
I am new to kamailio module devel...
I want to test a new scheduling for SIP messages... Can i do that with
kamailio modules? or I should go for something else? probably kamailio
core??
Regards,
Vineet Menon
Hello,
looking at ndb_redis module source code I see replies are not freed when
module is destroyed.
Also a reply is only freed when another one with same name is performed.
This could cause problems if an user would ask for
a lot of different named replies.
IMHO freeing reply list when module is destroyed and creating a new
redisc_free_reply function would solve this.
I attach a patch that compiles but not tested to show the idea.
If you agree I can perform the task, I suppose redisc_free_reply
function should also be exported in cmd_export_t module structure.
This solution would be compatible with old ndb redis module configuration.
Regards,
Vicente.