[SR-Users] Async module taking down our server
Will Ferrer
will.ferrer at switchsoft.com
Wed Jan 28 23:37:33 CET 2015
Hi Daniel
Yeah I am happy to be able to report the success. Thanks for everything as
always!
I hope you are well.
Will
On Wed, Jan 28, 2015 at 5:54 AM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:
> Hello,
>
> great that it was sorted out and it was not on Kamailio side :-)
>
> Also, glad to hear that async processing did increase capacity to handle
> more concurrent calls, even it was causing troubles to other applications
> ...
>
> Cheers,
> Daniel
>
>
> On 28/01/15 05:40, Will Ferrer wrote:
>
> Hello
>
> I wanted to give an update on this.
>
> My business partner that found the issue and has been monitoring the
> problem has tracked down the issue. It turns out that the features we
> implemented using the async module were leading to more calls going on con
> currently (as they were intended to) and this was causing and issue with
> voip monitor. So the issue was not with the Async module.
>
> All the best.
>
> Will Ferrer
>
> Switchsoft
>
> On Mon, Jan 19, 2015 at 8:43 PM, Will Ferrer <will.ferrer at switchsoft.com>
> wrote:
>
>> Hi All
>>
>> We are trying to use the async module to to delay sending a bye on from
>> one end of the call to the other.
>>
>> We are using async_route(routename, seconds) to delay
>> the WITHINDLG route. The idea is that in the future we want to be able to
>> have our billing min duration enforced (though currently we are having
>> issues with the dialog module that we are discussing in another thread).
>>
>> After running this on our deploy servers, the delays before sending on
>> the byes get longer and longer, and then kamailio goes down. Then the
>> receive udp buffer fills up.
>>
>> We tried it with both 4 and 400 async workers, and it made no difference.
>>
>> I am including a screen capture of the servers stats when this happens
>> taken from voip monitor.
>>
>> Here are the relevant parts of the config:
>>
>> ...
>> loadmodule "async.so"
>> ...
>> modparam("async", "workers", ASYNC_THREADS)
>> ...
>> request_route {
>> ...
>> route(DELAYED_BYE_STATIC);
>> ...
>> route[DELAYED_BYE_STATIC] {
>> xlog("L_DEBUG","route DELAYED_BYE_STATIC");
>> #!ifdef WITH_DELAYED_BYE_STATIC
>> if (is_method("BYE")) {
>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, from self \n");
>> #if (from_uri == myself) {
>> if ((allow_trusted() || allow_source_address()) && from_uri == myself) {
>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, Bye detected, from self \n");
>> send_reply("200", "OK");
>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, sent 200 about to sleep \n");
>> setflag(FLT_ACC); # do accounting ...
>> setflag(FLT_ACCFAILED); # ... even if the transaction fails
>> if (has_totag()) {
>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, sleeping to WITHINDLG_DELAYED
>> \n");
>> async_route("WITHINDLG_DELAYED", MIN_DURATION);
>> } else {
>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, sleeping to WITHINDLG \n");
>> async_route("WITHINDLG", MIN_DURATION);
>> }
>> xlog("L_DEBUG","route DELAYED_BYE_STATIC, slept\n");
>> exit;
>> }
>> }
>> #!endif
>> return;
>> }
>> ...
>> route[WITHINDLG_DELAYED] {
>> xlog("L_DEBUG", "route WITHINDLG_DELAYED: triggered \n");
>> $avp(was_delayed) = 1;
>> route(WITHINDLG);
>> }
>> ...
>> route[WITHINDLG] {
>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG triggered, request
>> method: $rm \n");
>> #!ifdef WITH_DISPATCHER
>> if(is_method("BYE|CANCEL")) {
>> xlog("L_DEBUG","route WITHINDLG: cancel or bye detected, request
>> method: $rm \n");
>> #!ifdef WITH_DISPATCHER_LOAD_AWARE
>> xlog("L_DEBUG","route WITHINDLG: running ds_load_update, request
>> method: $rm \n");
>> ds_load_update();
>> #dlg_get ("$ci","$ft","$tt");
>> #dlg_bye ("all");
>> #!endif
>> }
>> #!endif
>>
>> if (has_totag() || $avp(was_delayed) == 1) {
>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG has totag or was_delayed:
>> $avp(was_delayed) \n");
>> # sequential request withing a dialog should
>> # take the path determined by record-routing
>> if (loose_route()) {
>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG has loose route \n");
>> route(DLGURI);
>> if (is_method("BYE")) {
>> xlog("L_DEBUG","route WITHINDLG: BYE detected");
>> setflag(FLT_ACC); # do accounting ...
>> setflag(FLT_ACCFAILED); # ... even if the transaction fails
>> xlog("L_DEBUG","route WITHINDLG: ACC flag set");
>> }
>> else if ( is_method("ACK") ) {
>> # ACK is forwarded statelessy
>> route(NATMANAGE);
>> }
>> else if ( is_method("NOTIFY") ) {
>> # Add Record-Route for in-dialog NOTIFY as per RFC 6665.
>> record_route();
>> }
>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG RELAY 1\n");
>> route(RELAY);
>> } else {
>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG else \n");
>> if (is_method("SUBSCRIBE") && uri == myself) {
>> # in-dialog subscribe requests
>> route(PRESENCE);
>> exit;
>> }
>> if ( is_method("ACK") ) {
>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG is ack \n");
>> if ( t_check_trans() ) {
>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG t_check_trans \n");
>> # no loose-route, but stateful ACK;
>> # must be an ACK after a 487
>> # or e.g. 404 from upstream server
>> xlog("L_DEBUG", "route WITHINDLG: will -- DLG RELAY 2\n");
>> route(RELAY);
>> exit;
>> } else {
>> # ACK without matching transaction ... ignore and discard
>> exit;
>> }
>> }
>> sl_send_reply("404","Not here");
>> }
>> exit;
>> }
>> }
>> ...
>>
>>
>>
>> Does any one know if this is a bug or a leak with in the async module,
>> or perhaps something I am doing in my config?
>>
>> Thanks in advance for an assistance you can offer me.
>>
>> All the best.
>>
>> Will Ferrer
>> Switchsoft
>>
>>
>>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
> --
> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20150128/02faf3cd/attachment.html>
More information about the sr-users
mailing list