Send sr-dev mailing list submissions to
sr-dev@lists.sip-router.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
or, via email, send a message with subject or body 'help' to
sr-dev-request@lists.sip-router.org
You can reach the person managing the list at
sr-dev-owner@lists.sip-router.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of sr-dev digest..."
Today's Topics:
1. Re: accessing database from a child forked proces
(Daniel-Constantin Mierla)
----------------------------------------------------------------------
Message: 1
Date: Mon, 08 Sep 2014 16:37:21 +0200
From: Daniel-Constantin Mierla <miconda@gmail.com>
To: Luis Azedo <luis.azedo@factorlusitano.com>
Cc: "Kamailio \(SER\) - Development Mailing List"
<sr-dev@lists.sip-router.org>
Subject: Re: [sr-dev] accessing database from a child forked proces
Message-ID: <540DBF21.8070802@gmail.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hello,
On 08/09/14 15:29, Luis Azedo wrote:
> Hi Daniel,
>
> all problems solved with presence! i was not running child_init and
> now there is no need for the proposed patch to presence.
ok. Given this, would the db_text patch still be required, as there
should be no database connection sharing?
Cheers,
Daniel
>
> Thank you
>
>
>
> On Mon, Sep 8, 2014 at 2:13 PM, Luis Azedo
> <luis.azedo@factorlusitano.com <mailto:luis.azedo@factorlusitano.com>>
> wrote:
>
> Hi Daniel,
>
> this is the way we are creating the child processes (1 manager and
> n workers)
> the problem is with the workers.
> the worker will call a event-route and in the script config we try
> to call pres_refresh_watchers and that's where we get the pa_db =
> NULL.
>
> as i understand from your email, if we change PROC_NOCHLDINIT and
> let the child_init execute for the forked process then it will
> also execute child_init in other modules ? it makes sense.
>
> going to try this.
>
>
> static int mod_child_init(int rank)
> {
> int pid;
> int i;
>
> fire_init_event(rank);
>
> if (rank==PROC_MAIN) {
> pid=fork_process(PROC_NOCHLDINIT, "AMQP Manager", 1);
> if (pid<0)
> return -1; /* error */
> if(pid==0){
> kz_amqp_manager_loop(0);
> }
> else {
> for(i=0; i < dbk_consumer_processes; i++) {
> pid=fork_process(PROC_NOCHLDINIT, "AMQP Consumer", 1);
> if (pid<0)
> return -1; /* error */
> if(pid==0){
> mod_consumer_proc(i+1);
> }
> }
> }
> }
>
> return 0;
> }
>
>
>
> On Mon, Sep 8, 2014 at 1:11 PM, Daniel-Constantin Mierla
> <miconda@gmail.com <mailto:miconda@gmail.com>> wrote:
>
> Hello,
>
> the database connection should not be shared beween processes,
> because it can bring unexpected results in may places.
>
> Right now, the rule is to have one connection per process,
> shared by all modules in that process.
>
> To achieve that, at mod_init each module opens database
> connection and closes it before ending the function. Then in
> child_init() the connection is opened again. Another module
> that will have to open in child_init() will get the same
> connection now.
>
> When you create a new process, you tell the type of child and
> based on that child_init() from the other modules are executed.
>
> What is the function do you use for creating a new process?
> Maybe you can paste it here exactly how you do it and I can
> see if something can be done.
>
> Cheers,
> Daniel
>
>
> On 03/09/14 12:09, Luis Azedo wrote:
>> Hi Jason,
>>
>> thanks for the reply.
>>
>> the last 2 statements in presence module mod_init close the
>> connection and set pa_db to NULL. when my module main process
>> forks the extra processes the pa_db in presence is NULL, so
>> when it calls pres_refresh_watchers it fails because pa_db is
>> NULL.
>> i commented these last statements in presence mod_init and i
>> got it to work.
>>
>> // pa_dbf.close(pa_db);
>> // pa_db = NULL;
>>
>> does this have any implications on how the module works ? is
>> it ok to merge this change ?
>>
>> Thank you
>>
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 31 Aug 2014 09:40:49 +0200
>> From: Jason Penton <jason.penton@gmail.com
>> <mailto:jason.penton@gmail.com>>
>> To: "Kamailio (SER) - Development Mailing List"
>> <sr-dev@lists.sip-router.org
>> <mailto:sr-dev@lists.sip-router.org>>
>> Subject: Re: [sr-dev] accessing database from a child
>> forked process
>> Message-ID:
>>
>> <CALoGXNWvHhCAO91Tfa0w8W3eYQRvfV7Qkgte7dBnD+ciNr_Kpg@mail.gmail.com
>> <mailto:CALoGXNWvHhCAO91Tfa0w8W3eYQRvfV7Qkgte7dBnD%2BciNr_Kpg@mail.gmail.com>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> To confirm exactly what processes are being used, maybe
>> check the log file
>> and take note of process id at each log event. For
>> example you could check
>> the process id of the messages showing you the connection
>> is null. Then run
>> kamcmd ps to show the process list with a description of
>> each Kamailio
>> process. That will probably point you in the correct
>> direction.
>>
>> Cheers
>> Jason
>>
>>
>> On Fri, Aug 29, 2014 at 3:53 PM, Luis Azedo
>> <luis.azedo@factorlusitano.com
>> <mailto:luis.azedo@factorlusitano.com>>
>> wrote:
>>
>> > Hi,
>> >
>> > i have a module that creates 1 extra process where it
>> processes stuff in a
>> > loop.
>> > on some condition i fire a route_event with a fakemsg
>> and its up to the
>> > user of the module to take action, it tries to work
>> like dispatcher module
>> > or htable (mod-init) events.
>> >
>> > the problem that i have is that, if i call some
>> function on some module
>> > that performs a database action, the connection is null
>> when it calls
>> > use_table.
>> >
>> > in this case i'm making this call
>> > event_route[my_module:my_event]
>> > {
>> > $var(my_uri) = <<result of some operations>>;
>> > pres_refresh_watchers("$var(my_uri)", "dialog", 1);
>> > }
>> > presence module makes the call to use_table but this
>> call fails because
>> > the connection is null. presence module is working fine
>> besides this.
>> >
>> > if i make this call inside
>> event_route[dispatcher:dst-up] it works.
>> >
>> > i think that dispatcher fires the event inside a
>> callback from a
>> > registered timer, so, i think (may be wrong) that it
>> comes from a different
>> > process ?
>> >
>> > i wonder if i'm missing something from child_init ?
>> need to register
>> > something ?
>> >
>> > thanks for your help.
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > sr-dev mailing list
>> > sr-dev@lists.sip-router.org
>> <mailto:sr-dev@lists.sip-router.org>
>> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>> >
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140831/9fba51e4/attachment-0001.html>
>>
>> ------------------------------
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev@lists.sip-router.org
>> <mailto:sr-dev@lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>>
>> End of sr-dev Digest, Vol 70, Issue 71
>> **************************************
>>
>>
>>
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> --
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda
> Next Kamailio Advanced Trainings 2014 -http://www.asipto.com
> Sep 22-25, Berlin, Germany
>
>
>
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Next Kamailio Advanced Trainings 2014 - http://www.asipto.com
Sep 22-25, Berlin, Germany
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20140908/6da7f048/attachment.html>
------------------------------
_______________________________________________
sr-dev mailing list
sr-dev@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
End of sr-dev Digest, Vol 71, Issue 24
**************************************