VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
View previous topic :: View next topic |
Author |
Message |
venefax at gmail.com Guest
|
Posted: Thu Jul 14, 2016 6:26 pm Post subject: [asterisk-users] ODBC freezing Asterisk 13 |
|
|
Many people are reporting the same issue, so it is not my imagination. Asterisk 13 above 13.1 is useless for anybody who relies on res_odbc.so. As you know, after that version, the dropped the complexity of Pooling onto unix_odbc itself. Not so simple, it seems. I noticed that after a few hours of inactivity, any call to func_odbc-defined funcions will block and hang for ever. All we can do at that point is reset Asterisk.
I think it was highly rushed a decision to drop all the work done in ODBC inside Asterisk. Maybe unix_odbc pooling is not ready, has bugs, it cannot be used in production. I don't know what the issue is, but I had to downgrade to Asterisk 13.1 and my ODBC problems disappeared. Asterisk did not need to drop the ODBC pooling code. It did work. It should be fixed, made faster, etc. |
|
Back to top |
|
|
jcolp at digium.com Guest
|
Posted: Thu Jul 14, 2016 6:41 pm Post subject: [asterisk-users] ODBC freezing Asterisk 13 |
|
|
Saint Michael wrote:
Quote: | Many people are reporting the same issue, so it is not my imagination.
Asterisk 13 above 13.1 is useless for anybody who relies on
res_odbc.so. As you know, after that version, the dropped the complexity
of Pooling onto unix_odbc itself. Not so simple, it seems. I noticed
that after a few hours of inactivity, any call to func_odbc-defined
funcions will block and hang for ever. All we can do at that point is
reset Asterisk.
I think it was highly rushed a decision to drop all the work done in
ODBC inside Asterisk. Maybe unix_odbc pooling is not ready, has bugs, it
cannot be used in production. I don't know what the issue is, but I had
to downgrade to Asterisk 13.1 and my ODBC problems disappeared. Asterisk
did not need to drop the ODBC pooling code. It did work. It should be
fixed, made faster, etc.
|
This has already been done[1] and will be released in Asterisk 13.10,
which just had an rc3 released. I also sent an email to the list[2] when
the fix went in. These fixes have continued to show no problems
themselves although they just exposed an issue with func_odbc which was
fixed in the rc3 that was just released. There's no issues open
currently against that work.
As for the res_odbc changes themselves which exposed problems in
UnixODBC those went in as of Asterisk 13.8[3], not earlier.
Prior to 13.8 there was no pooling at all.
[1] http://blogs.asterisk.org/2016/06/15/asterisk-odbc-connections/
[2] http://lists.digium.com/pipermail/asterisk-users/2016-June/289326.html
[3] http://blogs.asterisk.org/2016/02/17/odbc_gutting/
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users |
|
Back to top |
|
|
maillist at lightspeed.ca Guest
|
Posted: Mon Jul 18, 2016 5:06 pm Post subject: [asterisk-users] ODBC freezing Asterisk 13 |
|
|
On 2016-07-14 16:40, Joshua Colp wrote:
Quote: | Saint Michael wrote:
Quote: | Many people are reporting the same issue, so it is not my
imagination.
Asterisk 13 above 13.1 is useless for anybody who relies on
res_odbc.so. As you know, after that version, the dropped the
complexity
of Pooling onto unix_odbc itself. Not so simple, it seems. I noticed
that after a few hours of inactivity, any call to func_odbc-defined
funcions will block and hang for ever. All we can do at that point is
reset Asterisk.
I think it was highly rushed a decision to drop all the work done in
ODBC inside Asterisk. Maybe unix_odbc pooling is not ready, has bugs,
it
cannot be used in production. I don't know what the issue is, but I
had
to downgrade to Asterisk 13.1 and my ODBC problems disappeared.
Asterisk
did not need to drop the ODBC pooling code. It did work. It should be
fixed, made faster, etc.
|
This has already been done[1] and will be released in Asterisk 13.10,
which just had an rc3 released. I also sent an email to the list[2]
when the fix went in. These fixes have continued to show no problems
themselves although they just exposed an issue with func_odbc which
was fixed in the rc3 that was just released. There's no issues open
currently against that work.
As for the res_odbc changes themselves which exposed problems in
UnixODBC those went in as of Asterisk 13.8[3], not earlier.
Prior to 13.8 there was no pooling at all.
[1] http://blogs.asterisk.org/2016/06/15/asterisk-odbc-connections/
[2]
http://lists.digium.com/pipermail/asterisk-users/2016-June/289326.html
[3] http://blogs.asterisk.org/2016/02/17/odbc_gutting/
|
Jumping Jesus on a pogo stick. And here, I was trying to build a version
of Asterisk 13.8-cert that 1) absolutely required ODBC because I
couldn't even build res_config_mysql.so anymore, and 2) I was trying to
get ODBC working on Ubuntu 16.04, in spite of it being, um, apparently
completely missing from the OS.
Well, I guess I can give up *that* fool's quest! This post has been most
illuminating!
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users |
|
Back to top |
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|