[sr-dev] ASYNC module question
Peter Dunkley
peter.dunkley at crocodile-rcs.com
Tue Mar 20 17:40:44 CET 2012
Thanks Daniel,
I'll stick with my complex configuration file for now, but I might take
a look at ASYNC sometime later if get a chance.
Thanks again,
Peter
On Tue, 2012-03-20 at 11:16 +0100, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 3/16/12 12:33 PM, Peter Dunkley wrote:
>
> > Hi,
> >
> > As part of some work to get the maximum performance out of Kamailio
> > RLS and Presence I would like to be able to hand-off processing of
> > presence requests (NOTIFY, PUBLISH, and SUBSCRIBE) to some worker
> > processes. This way, even if large numbers of presence requests are
> > received on a single TCP connection, all that the Kamailio process
> > managing that connection has to do is to de-packetise the requests
> > and hand them off.
> >
> > I have been looking at the ASYNC module and it doesn't seem to do
> > quite the right thing for this. The issue is the sleep parameter.
> > I want my worker processes to process presence requests continuously
> > from a queue, not suspend them for a second or more and then process
> > them. Is there a simple change to ASYNC to get it to do this?
> >
> > I currently do what I need in a quite different way (see config
> > fragment below), but I think using ASYNC would be cleaner if it did
> > what I needed...
> >
> > ...
> > # ----- mqueue params -----
> > modparam("mqueue", "mqueue", "name=presence")
> >
> > # ----- rtimer params -----
> > modparam("rtimer", "timer", "name=presence0;interval=1;mode=1;")
> > modparam("rtimer", "exec", "timer=presence0;route=PRESENCE_PROCESS")
> > modparam("rtimer", "timer", "name=presence1;interval=1;mode=1;")
> > modparam("rtimer", "exec", "timer=presence1;route=PRESENCE_PROCESS")
> > ...
> > modparam("rtimer", "timer", "name=presence7;interval=1;mode=1;")
> > modparam("rtimer", "exec", "timer=presence7;route=PRESENCE_PROCESS")
> > ...
> > if (@event!="presence" && @event!="presence.winfo") {
> > $var(ev_type) = @event;
> > xlog("L_INFO", " $rm $var(ev_type) not a presence message for myself\n");
> > return;
> > }
> >
> > if (!t_suspend()) {
> > t_reply("500", "Server Internal Error");
> > xlog("L_ERR", "Failed to suspend transaction for $rm\n");
> > exit;
> > }
> >
> > xlog("L_INFO", "Suspended transaction for $rm [$T(id_index):$T(id_label)]\n");
> >
> > if (!mq_add("presence", "$T(id_index)", "$T(id_label)")) {
> > t_reply("500", "Server Internal Error");
> > xlog("L_ERR", "Failed to queue transaction for $rm [$T(id_index):$T(id_label)]\n");
> > exit;
> > }
> > exit;
> > ...
> > route[PRESENCE_PROCESS] {
> > lock("pres");
> > $var(pres) = $shv(pres);
> > $shv(pres) = $shv(pres) + 1;
> > unlock("pres");
> >
> > xlog("L_WARN", "Starting presence de-queue process $var(pres) (pid: $pp)\n");
> >
> > while (1) {
> > while (mq_fetch("presence")) {
> > $var(id_index) = (int) $mqk(presence);
> > $var(id_label) = (int) $mqv(presence);
> > xlog("L_INFO", "Found queued presence transaction [$var(id_index):$var(id_label)]\n");
> > t_continue("$var(id_index)", "$var(id_label)", "PRESENCE");
> > }
> > usleep(100000);
> > }
> > }
> >
> > route[PRESENCE] {
> > xlog("L_INFO", "$rm: route[PRESENCE] process $var(pres)\n");
> >
> > if (is_method("NOTIFY")) {
> > xlog("L_INFO", "Sending NOTIFY to RLS\n");
> > rls_handle_notify();
> > } else if (is_method("PUBLISH")) {
> > xlog("L_INFO", "Sending PUBLISH to Presence\n");
> > handle_publish();
> > } else if (is_method("SUBSCRIBE")) {
> > xlog("L_INFO", "Sending SUBSCRIBE to RLS\n");
> > $var(ret_code) = rls_handle_subscribe();
> > if ($var(ret_code) == 10) {
> > xlog("L_INFO", " SUBSCRIBE not for RLS - sending to Presence\n");
> > handle_subscribe();
> > }
> > } else {
> > xlog("L_ERR", "Received non-(NOTIFY|SUBSCRIBE) request from presence queue\n");
> > t_reply("500", "Server Internal Error");
> > }
> > exit;
> > }
> >
> >
>
> just for the records, rtimer can do now micro-second timers -- that
> should lower waiting time for your example.
>
> It would be good to have also an 'immediate' execution of a route in
> async module, kind of embedding the above config functionality --
> having a list of tasks in shared memory (id_index, id_label) and a
> pool of workers checking and consuming it -- it will make config
> simpler for such needs, otherwise, the functionality can be achieved
> right now pretty much completely just via config.
>
> Cheers,
> Daniel
>
>
> --
> Daniel-Constantin Mierla
> Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
> http://www.asipto.com/index.php/kamailio-advanced-training/
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120320/f9b68369/attachment.htm>
More information about the sr-dev
mailing list