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