THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#482 - deadlock if calling t_check_trans() from failure route
User who did this - Andrew Pogrebennyk (marduk)
----------
Hi Daniel,
that doesn't seem to cover the per-branch failure routes. E.g., I arm event route with t_on_branch_failure("redirect"); then in the event_route[tm:branch-failure:redirect] I'm checking the response code and if it's 302|301 append a new branch and go to some request route. If I call then t_check_trans() in that request route I'm still getting a deadlock.
There is not much useful info that I can spot in the log file, e.g.:
Nov 10 14:00:18 sp1 proxy[7887]: DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=2 global id=2 T st
art=0x7face3e057b8
Nov 10 14:00:18 sp1 proxy[7887]: DEBUG: tm [t_lookup.c:1144]: t_check_msg(): DEBUG: t_check_msg: T already found!
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=482#comment1691
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.
The documentation for the fr_timer_avp/fr_inv_timer_avp modparams of TM say:
This parameter is kept for backwards compatibility (hence its
value expressed in seconds instead of milliseconds and its
arcane way of specifying the avps). The recommended replacement
is using t_set_fr() on a per transaction basis.
The problem is that, as far as I can see, t_set_fr() does not accept PV
arguments, so it is not a replacement except in cases where these values
are hard-coded.
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#490 - htable sht_lock problem
User who did this - Savolainen Dmitri (snen)
----------
my test looks OK. thanks.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=490#comment1690
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.
The following task has a new comment added:
FS#490 - htable sht_lock problem
User who did this - Daniel-Constantin Mierla (miconda)
----------
Can you test with latest master branch, I pushed a patch to htable that hopefully handles this issue.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=490#comment1689
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.
Module: sip-router
Branch: master
Commit: 44269cd654a6ab0557ca242f25ec41158e7dcbaf
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=44269cd…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Sat Nov 8 11:10:11 2014 +0100
htable: elaborated docs about sht_lock() and sht_unlock()
---
modules/htable/README | 8 ++++++--
modules/htable/doc/htable_admin.xml | 8 ++++++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/modules/htable/README b/modules/htable/README
index 1a0ec5c..8ffde42 100644
--- a/modules/htable/README
+++ b/modules/htable/README
@@ -672,7 +672,9 @@ sht_reset("ha$var(x)");
4.5. sht_lock(htable=>key)
- Lock the slot in htable corespoding to the key item.
+ Lock the slot in htable corespoding to the key item. Note that the
+ locking is re-entrant for the process, therefore the lock and unlock
+ should be done by the same process.
This function can be used from ANY_ROUTE.
@@ -683,7 +685,9 @@ sht_lock("ha=>test");
4.6. sht_unlock(htable=>key)
- Unlock the slot in htable corespoding to the key item.
+ Unlock the slot in htable corespoding to the key item. Note that the
+ locking is re-entrant for the process, therefore the lock and unlock
+ should be done by the same process.
This function can be used from ANY_ROUTE.
diff --git a/modules/htable/doc/htable_admin.xml b/modules/htable/doc/htable_admin.xml
index 9b5fe7a..2e78d0c 100644
--- a/modules/htable/doc/htable_admin.xml
+++ b/modules/htable/doc/htable_admin.xml
@@ -741,7 +741,9 @@ sht_reset("ha$var(x)");
<function moreinfo="none">sht_lock(htable=>key)</function>
</title>
<para>
- Lock the slot in htable corespoding to the key item.
+ Lock the slot in htable corespoding to the key item. Note that
+ the locking is re-entrant for the process, therefore the lock
+ and unlock should be done by the same process.
</para>
<para>
This function can be used from ANY_ROUTE.
@@ -760,7 +762,9 @@ sht_lock("ha=>test");
<function moreinfo="none">sht_unlock(htable=>key)</function>
</title>
<para>
- Unlock the slot in htable corespoding to the key item.
+ Unlock the slot in htable corespoding to the key item. Note that
+ the locking is re-entrant for the process, therefore the lock
+ and unlock should be done by the same process.
</para>
<para>
This function can be used from ANY_ROUTE.