12 Oct
2017
12 Oct
'17
7:03 p.m.
Hi, community!
I have in my Kamailio script following block (while REGISTER processing,
after auth succeed):
.....
/* Save to usrloc */
lock("LOCATION_LOCK");
if (!save("location")) {
unlock("LOCATION_LOCK");
sl_reply_error();
exit();
}
unlock("LOCATION_LOCK");
......
According to module documentation - if "save" - failed (for any reason) - I
expected the control to be returned to the script with error code "-1"
But, there are cases - when this does not happen - which lead to deadlock
for workers processing REGISTERs (I never unlock("LOCATION_LOCK")):
- module answers with internal error - and return 0 from "save" function:
https://github.com/kamailio/kamailio/blob/master/src/modules/registrar/save…
- line 1013
My use case happened due to malfunctioning device that in some moment of
time:
- send REGISTER update
- kamailio answers 200OK
- device retransmit the same REGISTER (same CSeq)
- during 20 seconds (hardcoded value in registrar module) - kamailio answers
200OK (and everything is ok)
- if retransmission continue more than 20s - kamailio answered 400 Bad
request, and did not return control to script (as a result I had no chance
to unlock("LOCATION_LOCK") from code above)
Tested it on kamailio 4.2.5 and 5.0.3.
as for me, possible solutions are:
- return -1 instead of 0 from "save" by default
- if there are some reasons not to do this - we should change documentation,
and explicitly mention that there are cases - when script execution is
stopped.
thanks in advance!
cheers
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
13 Oct
13 Oct
11:42 a.m.
Hi,
indeed, when a function returns with 0, Kamailio immediately ends the
processing of the packet. So that's why the unlock statement is never
executed.
I am wondering, why you are using locks at this point. That way, only
one REGISTER can be processed at the same time, since they all share
the same lock. I've never seen somebody do this before, and multiple
REGISTERs being processed in parallel should be no problem. What
problem do you try to solve by surrounding the save command with
locks?
Best Regards,
Sebastian
On Thu, Oct 12, 2017 at 6:03 PM, Vasiliy Ganchev <vancecezar(a)gmail.com> wrote:
Hi, community!
I have in my Kamailio script following block (while REGISTER processing,
after auth succeed):
.....
/* Save to usrloc */
lock("LOCATION_LOCK");
if (!save("location")) {
unlock("LOCATION_LOCK");
sl_reply_error();
exit();
}
unlock("LOCATION_LOCK");
......
According to module documentation - if "save" - failed (for any reason) - I
expected the control to be returned to the script with error code "-1"
But, there are cases - when this does not happen - which lead to deadlock
for workers processing REGISTERs (I never unlock("LOCATION_LOCK")):
- module answers with internal error - and return 0 from "save" function:
https://github.com/kamailio/kamailio/blob/master/src/modules/registrar/save…
- line 1013
My use case happened due to malfunctioning device that in some moment of
time:
- send REGISTER update
- kamailio answers 200OK
- device retransmit the same REGISTER (same CSeq)
- during 20 seconds (hardcoded value in registrar module) - kamailio answers
200OK (and everything is ok)
- if retransmission continue more than 20s - kamailio answered 400 Bad
request, and did not return control to script (as a result I had no chance
to unlock("LOCATION_LOCK") from code above)
Tested it on kamailio 4.2.5 and 5.0.3.
as for me, possible solutions are:
- return -1 instead of 0 from "save" by default
- if there are some reasons not to do this - we should change documentation,
and explicitly mention that there are cases - when script execution is
stopped.
thanks in advance!
cheers
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
3:30 p.m.
Hi Sebastian!
Thanks for your response!
In our system we have:
- usrloc with db_mode=1 (Write-Through scheme. All changes to usrloc are
immediately reflected in database too. )
- sqlite DB, to store location info (sqlite is blocking for the time of
write, and if there are 2 write attempts by 2 workers - one of them fails)
In this scheme - I definitely need to process only one REGISTER at the same
time (In our setup kamailio are not high loaded)
And locking - seemed to me the safest workaround for production (as turned
out - it did not).
What I am doing now - is testing my kamailio with usrloc db_mode=2
(Write-Back scheme.) (and this is going to be production solution soon)
I posted the topic - to discuss my case - and make some changes (sources or
documentation) - to prevent someone else in future to encounter something
similar.
cheers
a registrar module working
Sebastian Damm-2 wrote
Hi,
indeed, when a function returns with 0, Kamailio immediately ends the
processing of the packet. So that's why the unlock statement is never
executed.
I am wondering, why you are using locks at this point. That way, only
one REGISTER can be processed at the same time, since they all share
the same lock. I've never seen somebody do this before, and multiple
REGISTERs being processed in parallel should be no problem. What
problem do you try to solve by surrounding the save command with
locks?
Best Regards,
Sebastian
On Thu, Oct 12, 2017 at 6:03 PM, Vasiliy Ganchev <
vancecezar@
> wrote:
> Hi, community!
>
> I have in my Kamailio script following block (while REGISTER processing,
> after auth succeed):
>
> .....
> /* Save to usrloc */
> lock("LOCATION_LOCK");
> if (!save("location")) {
> unlock("LOCATION_LOCK");
> sl_reply_error();
> exit();
> }
> unlock("LOCATION_LOCK");
>
> ......
>
> According to module documentation - if "save" - failed (for any reason) -
> I
> expected the control to be returned to the script with error code "-1"
>
> But, there are cases - when this does not happen - which lead to deadlock
> for workers processing REGISTERs (I never unlock("LOCATION_LOCK")):
> - module answers with internal error - and return 0 from "save" function:
> https://github.com/kamailio/kamailio/blob/master/src/modules/registrar/save…
> - line 1013
>
> My use case happened due to malfunctioning device that in some moment of
> time:
> - send REGISTER update
> - kamailio answers 200OK
> - device retransmit the same REGISTER (same CSeq)
> - during 20 seconds (hardcoded value in registrar module) - kamailio
> answers
> 200OK (and everything is ok)
> - if retransmission continue more than 20s - kamailio answered 400 Bad
> request, and did not return control to script (as a result I had no
> chance
> to unlock("LOCATION_LOCK") from code above)
>
> Tested it on kamailio 4.2.5 and 5.0.3.
>
> as for me, possible solutions are:
> - return -1 instead of 0 from "save" by default
> - if there are some reasons not to do this - we should change
> documentation,
> and explicitly mention that there are cases - when script execution is
> stopped.
>
> thanks in advance!
>
> cheers
>
>
>
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
>
sr-users@.kamailio
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@.kamailio
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
30 Oct
30 Oct
11:21 a.m.
Hi there again!
@Daniel, can you comment what do you think about the topic?
Thanks in advance!
cheers!
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
12:40 p.m.
Hello,
On 30.10.17 09:21, Vasiliy Ganchev wrote:
Hi there again!
@Daniel, can you comment what do you think about the topic?
I changed to return -1. Not sure what was the reason to return 0 there,
but was not the expected behaviour. Patch pushed to master and 5.0
branches for now.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
2:54 p.m.
@Daniel, thanks for the answer and for the change accepting!
have a nice day!
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
2583
days inactive
2601
days old
5 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Sebastian Damm -
Vasiliy Ganchev