An example of what happens -- on processing a call right before a database lookup (the select query below in the previous message):<br><br>00:00:00 pgpool: opensips my_database localhost(46362) SELECT<br>postgres   445   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46383) SELECT<br>
postgres   446   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   447   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   448   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>
postgres   449   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   450   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   451   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46366) SELECT<br>
postgres   452   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46371) SELECT<br>postgres   453   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   454   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46367) SELECT<br>
postgres   455   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46372) SELECT<br>postgres   456   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46393) idle<br>postgres   457   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46391) SELECT<br>
postgres   458   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46377) SELECT<br>postgres   459   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46378) SELECT<br>postgres   460   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46374) SELECT<br>
postgres   461   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   462   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46387) SELECT<br>postgres   463   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>
postgres   464   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46380) SELECT<br>postgres   465   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   466   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46385) SELECT<br>
postgres   468   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46389) SELECT<br>postgres   469   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46361) SELECT<br>postgres   471   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>
postgres   473   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   474   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   475   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>
postgres   476   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   477   438  0 09:00 ?        00:00:00 pgpool: wait for connection request<br>postgres   478   438  0 09:00 ?        00:00:00 pgpool: opensips my_database localhost(46365) SELECT<br>
<br>I have 32 &quot;available&quot; connections, 16 of which are occupied by opensips children processes.  On this one query, it looks like &quot;every&quot; opensips process does the same processing to *all* the pgpool connections.  This is just for a single INVITE.  I don&#39;t know if the database lookup is failing or not, but it looks like the next child processes the message until none are left?<br>
<br>It will kind of just float here in this state for some time now -- I&#39;ve got a heartbeat script that can come back and clean this up (transparent to the endusers as we&#39;re in a failover setup), but I would like to know how to go about troubleshooting this particular type of issue.<br>
<br>I know it&#39;s not the database dying or pgpool losing it&#39;s connections, as I have logging enabled on both.<br><br>Any suggestions on troubleshooting, or has anyone tried this sort of configuration before?<br><br>
Thanks much in advance.<br><br><div class="gmail_quote">On Thu, Apr 16, 2009 at 4:39 PM, Bobby Smith <span dir="ltr">&lt;<a href="mailto:bobby.smith@gmail.com">bobby.smith@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
All,<br><br>We&#39;re currently (successfully) testing a configuration of Opensips as a stateless proxy.  I wanted to be able to execute an arbitrary database query to a database that&#39;s NOT the opensips database, when I realized the power of the avp_db_query( ) function in avpops.  The database is a backend postgres database in an basic failover configuration (16 max connections cached, primary db, failover to secondary db for those connections).<br>

<br>Currently, opensips has 16 children processes.  In the configuration, we have the following:<br><br>modparam(&quot;avpops&quot;, &quot;db_url&quot;, &quot;postgres://opensips:opensips@localhost:9999/my_database&quot;)<br>

modparam(&quot;avpops&quot;, &quot;avp_table&quot;, &quot;&quot;)<br><br>A few of the issues I&#39;m concerned about or experiencing with the operation of it.<br><br>a) Why is that second parameter necessary (avp_table)?  It feels like if I have to set this that it&#39;s always going to keep open connections with the database, and indeed, it is.  When I ps -ef, it shows I have 16 pgpool connections that are idle to my_database.  The problem that this is causing is that, if for some reason one of the connections has an issue and dies or times out, this happens in the logs:<br>

<br>Apr 16 05:46:02 serinbound1 /sbin/opensips[30773]: ERROR:db_postgres:db_postgres_store_result: 0x76e008 - invalid query, execution aborted<br>Apr 16 05:46:02 serinbound1 /sbin/opensips[30773]: ERROR:db_postgres:db_postgres_store_result: 0x76e008: PGRES_FATAL_ERROR<br>

Apr 16 05:46:02 serinbound1 /sbin/opensips[30773]: ERROR:db_postgres:db_postgres_store_result: 0x76e008: server closed the connection unexpectedly#012#011This probably means the server terminated abnormally#012#011before or while processing the request.#012<br>

Apr 16 05:46:02 serinbound1 /sbin/opensips[30773]: ERROR:core:db_do_raw_query: error while storing result<br>Apr 16 05:46:02 serinbound1 /sbin/opensips[30773]: ERROR:avpops:db_query_avp: cannot do the query<br>Apr 16 05:46:02 serinbound1 /sbin/opensips[30773]: Database Error!  No Lookup!<br>

Apr 16 05:46:02 serinbound1 /sbin/opensips[30773]: Query Executed:  Account Number is &lt;null&gt;<br><br>The query I&#39;m executing (from the config):  <br>avp_db_query(&quot;SELECT value FROM schema.table WHERE value = &#39;$avp(s:string_a)&#39;&quot;, &quot;$avp(s:string_b)&quot;);<br>

<br>When these error messages pop up, pgpool still has active database connections to postgres, but not held by opensips.  I can use one of the pooled connections to connect to the backend database and execute a query, but for some reason opensips cannot.<br>

<br>And, having a restart work (scripted), I occasionally see the following:<br><br>Apr 16 03:59:05 serinbound2 /sbin/opensips[23105]: ERROR:db_postgres:db_postgres_new_connection: server closed the connection unexpectedly#012#011This probably means the server terminated abnormally#012#011before or while processing the request.#012<br>

Apr 16 03:59:05 serinbound2 /sbin/opensips[23105]: ERROR:db_postgres:db_postgres_new_connection: cleaning up 0x76e090=pkg_free()<br>Apr 16 03:59:05 serinbound2 /sbin/opensips[23105]: ERROR:core:db_do_init: could not add connection to the pool<br>

Apr 16 03:59:05 serinbound2 /sbin/opensips[23105]: ERROR:avpops:avpops_db_init: cannot initialize database connection<br>Apr 16 03:59:05 serinbound2 /sbin/opensips[23105]: ERROR:core:init_mod_child: failed to initializing module avpops, rank -1<br>

Apr 16 03:59:05 serinbound2 /sbin/opensips[23105]: ERROR:core:start_timer_processes: init_child failed for timer proc<br>Apr 16 03:59:05 serinbound2 /sbin/opensips[23083]: INFO:core:handle_sigs: child process 23105 exited normally, status=255<br>

Apr 16 03:59:05 serinbound2 /sbin/opensips[23083]: INFO:core:handle_sigs: terminating due to SIGCHLD<br>Apr 16 03:59:05 serinbound2 /sbin/opensips[23107]: INFO:core:sig_usr: signal 15 received<br><br>At this point, the application crashes.<br>

<br>Any suggestions or workarounds for this?  More specifically, I&#39;d like opensips to not have to grab the DB connection if it doesn&#39;t need it at that time performing a lookup (as i&#39;m not really using avp&#39;s in the lookup, just to save the results), also, I&#39;d like to see it not crash completely if it loses that connection.  Instead, just send a error message back and allow me to insert a statement like:<br>

<br>               if(! what i expect the value of the saved avp from teh database query to be)<br>                {<br>                        sl_send_reply(&quot;500&quot;, &quot;Internal Server Error&quot;);<br>                        exit;<br>

                }<br><br>Thanks for your help, I know this was fairly detailed but without much in terms of logging.<br><br><br>
</blockquote></div><br>