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 <[email protected] <mailto:[email protected]>> 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
    <[email protected] <mailto:[email protected]>> 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 <[email protected]
            <mailto:[email protected]>>
            To: "Kamailio (SER) - Development Mailing List"
                    <[email protected]
            <mailto:[email protected]>>
            Subject: Re: [sr-dev] accessing database from a child
            forked process
            Message-ID:
<calogxnwvhhcao91tfa0w8w3eyqrvfv7qkgte7dbnd+cinr_...@mail.gmail.com
            
<mailto:calogxnwvhhcao91tfa0w8w3eyqrvfv7qkgte7dbnd%[email protected]>>
            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
            <[email protected]
            <mailto:[email protected]>>
            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
            > [email protected]
            <mailto:[email protected]>
            > 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
            [email protected]
            <mailto:[email protected]>
            http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


            End of sr-dev Digest, Vol 70, Issue 71
            **************************************




        _______________________________________________
        sr-dev mailing list
        [email protected]  <mailto:[email protected]>
        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

_______________________________________________
sr-dev mailing list
[email protected]
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Reply via email to