[OpenSIPS-Users] 2.2 crash with async, db_virtual and unixodbc
Jeff Pyle
JPyle at fusionconnect.com
Wed Sep 7 13:18:10 CEST 2016
Hi Răzvan ,
Ok. I found this on the 2.2 release info page:
2.27 DB_VIRTUAL module
added async raw query support
I thought I might be able to wrap db_virtual around unixodbc and get it to work. Apparently not! Or, at least not yet.
My application is to attempt to replace an aging Kamailio proxy with an OpenSIPS one in async mode. Unfortunately I don't have control over the data or where it lives; it's stuck in an MSSQL server. Actually, in a few geographically distributed but otherwise equal MSSQL servers so the db_virtual layer was perfect.
rest_get is mentioned as an available to async. I don't know much about rest but I'll look at writing a wrapper of sorts to get to the stored procedure that way. I'm open to any suggestions!
- Jeff
From: users-bounces at lists.opensips.org [mailto:users-bounces at lists.opensips.org] On Behalf Of Razvan Crainea
Sent: Wednesday, September 07, 2016 4:07 AM
To: users at lists.opensips.org
Subject: Re: [OpenSIPS-Users] 2.2 crash with async, db_virtual and unixodbc
Hi, Jeff!
Unfortunately async operations are only supported by the MySQL backend, therefore it won't work with unixodbc or other backends. Now it crashes because of a mishandling in the db_virtual module. We are working on a fix for the crash, but even after the fix, you will still be unable to run async queries with unixodbc.
If you really want to do it async, then you should use MySQL backend. Also, don't forget to open a feature request on the issues page[1] to support async queries for unixodbc.
[1] https://github.com/OpenSIPS/opensips/issues
Best regards,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com<http://www.opensips-solutions.com>
On 09/07/2016 04:16 AM, Jeff Pyle wrote:
Hello,
I'm working from the 2.2 nightly build repo on Debian Jessie, 64-bit, specifically, 2.2.1~20160830~7261cf0-1.
I have a simple test script that runs a stored procedure on a Microsoft SQL 2014 server and xlogs the returned AVPs. This works fine. When I break it up into an async() function and a return route block, I get a crash every time.
Script:
route {
xlog("L_INFO", "Sending query...\n");
async(avp_db_query("exec dbo.doStuff '1','2','3','4'",
"$avp(db1);$avp(db2);$avp(db3)"), post_db_dip);
}
route [post_db_dip] {
xlog("L_INFO", "Back from query.\n");
while (is_avp_set("$avp(db1)") && is_avp_set("$avp(db2)") && is_avp_set("$avp(db3)")) {
xlog("L_INFO", "db1=$avp(db1), db2=$avp(db2), db3=$avp(db3)\n");
avp_delete("$avp(db1)");
avp_delete("$avp(db2)");
avp_delete("$avp(db3)");
}
xlog("L_INFO", "End of processing.\n");
sl_send_reply("600", "Road Closed");
exit;
}
The debug=6:
...
/usr/sbin/opensips[19887]: DBG:avpops:ops_async_dbquery: query [exec dbo.doStuff '1','2','3','4']
/usr/sbin/opensips[19887]: DBG:db_virtual:db_virtual_async_raw_query: f call handle size = 1
/usr/sbin/opensips[19887]: DBG:db_virtual:try_reconnect: try reconnect
/usr/sbin/opensips[19887]: DBG:db_virtual:db_virtual_async_raw_query: flags1 = 3
/usr/sbin/opensips[19883]: DBG:core:handle_sigs: status = 11
/usr/sbin/opensips[19883]: INFO:core:handle_sigs: child process 19887 exited by a signal 11
/usr/sbin/opensips[19883]: INFO:core:handle_sigs: core was not generated
/usr/sbin/opensips[19883]: INFO:core:handle_sigs: terminating due to SIGCHLD
/usr/sbin/opensips[19890]: INFO:core:sig_usr: signal 15 received
/usr/sbin/opensips[19889]: INFO:core:sig_usr: signal 15 received
/usr/sbin/opensips[19888]: INFO:core:sig_usr: signal 15 received
/usr/sbin/opensips[19886]: INFO:core:sig_usr: signal 15 received
/usr/sbin/opensips[19885]: INFO:core:sig_usr: signal 15 received
/usr/sbin/opensips[19884]: INFO:core:sig_usr: signal 15 received
/usr/sbin/opensips[19883]: INFO:core:cleanup: cleanup
...and so forth.
The process that crashes, 19887 in this particular case, is a listener process. I never see the "Back from xlog" xlog appear. OpenSIPS immediately respawns but I suspect that's systemd.
Am I doing something wrong, or is this a bug?
- Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160907/3f35ac17/attachment.htm>
More information about the Users
mailing list