Skip to content
Snippets Groups Projects
Select Git revision
20 results
Search by author
  • Any Author
  • Adam Porteous Adam Porteous adam.porteous
  • Alex Hopkins Alex Hopkins 59hopper
  • Amin Ben Romdhane Amin Ben Romdhane amin.benromdhane
  • Andreas Gnau Andreas Gnau AGnau
  • Andrej Kucharik Andrej Kucharik andrej.kucharik
  • Andrii Pypa Andrii Pypa andrii.pypa
  • Anjan Chanda Anjan Chanda anjancx
  • Balalakshmi Arunachalam Rajendran Balalakshmi Arunachalam Rajendran arbala
  • Benjamin Larsson Benjamin Larsson benjamin
  • Charles Foster Charles Foster charles.foster_bt.com
  • Dariusz Iwanoczko Dariusz Iwanoczko dariusz.iwanoczko
  • Divya Chandrasekaran Divya Chandrasekaran divya.c
  • Dominic Lake Dominic Lake dominic.lake
  • Elena Vengerova Elena Vengerova helen
  • Erik Karlsson Erik Karlsson erik.karlsson
  • Filip Matusiak Filip Matusiak filmat
  • Filip Strelec Filip Strelec filip.strelec
  • Fredrik Östling Fredrik Östling fredrik.ostling
  • Geoff Elliott Geoff Elliott gdelliott
  • George Yang George Yang gyang
20 authors
  1. Mar 24, 2022
  3. Dec 02, 2021
  5. Nov 19, 2021
  7. Nov 20, 2020
  9. Feb 07, 2019
    • Joshua Colp's avatar
      res_odbc: Add basic query logging. · 54a912b2
      Joshua Colp authored 
      When Asterisk is connected and used with a database the response
time of the database can cause problems in Asterisk if it is long.
Normally the only way to see this problem would be to retrieve a
backtrace from Asterisk and examine where things are blocked, or
examine the database to see if there is any indication of a
problem.

This change adds some basic query logging to make it easier to
investigate such a problem. When logging is enabled res_odbc will
now keep track of the number of queries executed, as well as the
query that has taken the longest time to execute. There is also
an option which will cause a WARNING message to be output if a
query takes longer than a configurable amount of time to execute.

This makes it easier and clearer for users that their database may
be experiencing a problem that could impact Asterisk.

ASTERISK-28277

Change-Id: I173cf4928b10754478a6a8c27dfa96ede0f058a6
      54a912b2
  11. Nov 21, 2018
  13. Sep 26, 2018
    • Alexei Gradinari's avatar
      res_odbc: fix missing SQL error diagnostic · e6a69ea2
      Alexei Gradinari authored 
      On SQL error there is not diagnostic information about this error.
There is only
WARNING res_odbc.c: SQL Execute error -1!

The function ast_odbc_print_errors calls a SQLGetDiagField to get the number
of available diagnostic records, but the SQLGetDiagField returns 0.
However SQLGetDiagRec could return one diagnostic records in this case.

Looking at many example of getting diagnostics error information
I found out that the best way it's to use only SQLGetDiagRec
while it returns SQL_SUCCESS.

Also this patch adds calls of ast_odbc_print_errors on SQL_ERROR
to res_config_odbc.

ASTERISK-28065 #close

Change-Id: Iba5ae5470ac49ecd911dd084effbe9efac68ccc1
      e6a69ea2
  15. Aug 15, 2018
  17. Mar 17, 2018
    • Alexander Traud's avatar
      BuildSystem: Remove unused dependency on libltdl. · 10a97882
      Alexander Traud authored 
      Asterisk does not need the development package of libltdl, because it does not
use any symbol of -lltdl directly. Instead, it uses the runtime package via the
shared library -lodbc. On the supported platforms, that shared library declares
its dependency on -lltdl correctly, otherwise AST_EXT_LIB_CHECK would have
failed.

ASTERISK-27745

Change-Id: Icd315809b8e7978203431f3afb66240dd3a040ba
      10a97882
  19. Jan 07, 2018
    • Alexander Traud's avatar
      General: Silence modules on (un)load. · 7e9781c2
      Alexander Traud authored 
      Some (normally optional) modules created notices, warnings, and even errors
in normal situations like (un)load. This cluttered the command-line interface
(CLI) on start and while stopping gracefully. However, when an user went for
the script './contrib/scripts/install_prereq', those modules get compiled-in
because their prerequisites were met at compile time. Furthermore, because of
ASTERISK_27475, the former talkative module 'res_curl' is built as side-effect.

ASTERISK-27553

Change-Id: I9f105f46d72553994e820679bfde3478a551b281
      7e9781c2
  21. Dec 22, 2017
  23. Jul 05, 2017
    • Sean Bright's avatar
      core: Remove 'Data Retrieval API' · 325eeced
      Sean Bright authored 
      This API was not actively maintained, was not added to new modules
(such as res_pjsip), and there exist better alternatives to acquire the
same information, such as the ARI.

Change-Id: I4b2185a83aeb74798b4ad43ff8f89f971096aa83
      325eeced
  25. Oct 27, 2016
    • Corey Farrell's avatar
      Remove ASTERISK_REGISTER_FILE. · a6e5bae3
      Corey Farrell authored 
      ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.

Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename

This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled.  This variable was only used in lock.c so it
is now initialized in that file only.

ASTERISK-26480 #close

Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
      a6e5bae3
  27. Sep 21, 2016
    • Joshua Colp's avatar
      res_odbc: Make pooling option deprecation notice more useful. · 077caf56
      Joshua Colp authored 
      This changes the notice for the deprecation of the old
pooling options to point to the new option for doing
pooling. This gives a clearer direction as to what to
look into.

ASTERISK-26389 #close

Change-Id: I2ca9cdfdcd75aec170a7db9d5ff69a4cd25b7c10
      077caf56
  29. Aug 18, 2016
  31. Aug 06, 2016
    • Rodrigo Ramírez Norambuena's avatar
      res_odbc: Show only when there a fail attempt of connection in CLI · 0749f6e6
      Rodrigo Ramírez Norambuena authored 
      When is executed CLI command "odbc show all" every time is show
information about variable last_negative_connect. If not there  a fail
attempt of connection will show date like "1969-12-31 21:00:00".

This patch fix there situation for to show only this information when
exists a fail attempt before.

Change-Id: I7c058b0be6f7642e922de75ee6b82c7276c9f113
      0749f6e6
  33. Jul 12, 2016
    • Joshua Colp's avatar
      func_odbc: Fix connection deadlock. · 4ad333bb
      Joshua Colp authored 
      The func_odbc module was modified to ensure that the
previous behavior of using a single database connection
was maintained. This was done by getting a single database
connection and holding on to it. With the new multiple
connection support in res_odbc this will actually starve
every other thread from getting access to the database as
it also maintains the previous behavior of having only
a single database connection.

This change disables the func_odbc specific behavior if
the res_odbc module is running with only a single database
connection active. The connection is only kept for the
duration of the request.

ASTERISK-26177 #close

Change-Id: I9bdbd8a300fb3233877735ad3fd07bce38115b7f
      4ad333bb
  35. Jun 07, 2016
    • Joshua Colp's avatar
      res_odbc: Implement a connection pool. · 31a5c283
      Joshua Colp authored 
      Testing has shown that our usage of UnixODBC is problematic
due to bugs within UnixODBC itself as well as the heavy weight
cost of connecting and disconnecting database connections, even
when pooling is enabled.

For users of UnixODBC 2.3.1 and earlier crashes would occur due
to insufficient protection of the disconnect operation. This was
fixed in UnixODBC 2.3.2 and above.

For users of UnixODBC 2.3.3 and higher a slow-down would occur
under heavy database use due to repeated connection establishment.
A regression is present where on each connection the database
configuration is cached again, with the cache growing out of
control.

The connection pool implementation present in this change helps
to mitigate these issues by reducing how much we connect and
disconnect database connections. We also solve the issue of
crashes under UnixODBC 2.3.1 by defaulting the maximum number of
connections to 1, returning us to the previous working behavior.
For users who may have a fixed version the maximum concurrent
connection limit can be increased helping with performance.

The connection pool works by keeping a list of active connections.
If the connection limit has not been reached a new connection is
established. If the connection limit has been reached then the
request waits until a connection becomes available before
continuing.

ASTERISK-26074 #close
ASTERISK-26054 #close

Change-Id: I6774bf4bac49a0b30242c76a09c403d2e856ecff
      31a5c283
  37. Feb 03, 2016
    • George Joseph's avatar
      logging: Remove/fix some message annoyances · dcbedf9a
      George Joseph authored 
      test_dlinklists doesn't need to NOTICE everyone that every macro worked.

res_phoneprov doesn't need to VERBOSE everyone that a phoneprov extension or
provider was registered.

res_odbc was missing a newline at the end of one message.

Change-Id: I6c06361518ef3711821795e535acd439782a995e
      dcbedf9a
  39. Jan 22, 2016
    • Mark Michelson's avatar
      res_odbc: Remove connection management · 9714da7a
      Mark Michelson authored 
      Asterisk by default will create a single database connection and share
it among all threads that attempt to access the database. In previous
versions of Asterisk, this was tolerable, because the most used channel
driver, chan_sip, mostly accessed the database from a single thread.
With PJSIP, however, many threads may be attempting to perform database
operations, and there is the potential for many more database accesses,
meaning the concurrency is a horrible bottleneck if only one connection
is shared.

Asterisk has a connection pooling facility built into it, but the
implementation has flaws. For one, there is a strict limit on the number
of simultaneous connections that could be made to the database. Anything
beyond the maximum would result in a failed operation. Attempting to
predict what the maximum should be is nearly impossible even for someone
intimately familiar with Asterisk's threading model. In addition, use of
transactions in the dialplan can cause some severe bugs if connection
pooling is enabled.

This commit seeks to fix the concurrency problem by removing all
connection management code from Asterisk and leaving that to the
underlying unixODBC code instead. Now, Asterisk does not share a single
connection, nor does it try to maintain a connection pool. Instead, all
Asterisk ever does is request a connection from unixODBC and allow
unixODBC to either allocate those connections or retrieve them from a
pool.

Doing this has a bit of a ripple effect. For one, since connections are
not long-lived objects, several of the safeguards that previously
existed have been removed. We don't have to worry about trying to use a
connection that has gone stale. In every case, when we request a
connection, it has just been made and we don't need to perform any
sanity checks to be sure it's still active.

Another major player affected by this change is transactions.
Transactions and their respective connections were so tightly coupled
that it was almost pornographic. This code change moves
transaction-related code to its own file separate from the core ODBC
functionality. This way, the core of ODBC does not even have to know
that transactions exist.

In making this large change, I had to look at a lot of code and
understand it. When making this change, I discovered several places
where the behavior is definitely not ideal, but it seemed outside the
scope of this change to be fixing it. Instead, any place where I saw
some sort of room for improvement has had a XXX comment added explaining
what could be altered to improve it.

Change-Id: I37a84def5ea4ddf93868ce8105f39de078297fbf
      9714da7a
  41. May 13, 2015
  43. May 04, 2015
    • Martin Tomec's avatar
      res_odbc: Use negative connection cache for all connections · ebe37135
      Martin Tomec authored 
      Apply the negative connection cache setting to all connections,
even those that are not pooled. This ensures that the connection
will not be  re-established before the negative connection cache
time is met.

ASTERISK-22708 #close

Change-Id: I431cc2e8584ab0b6908b3523d0a0e18c9a527271
      ebe37135
  45. Apr 13, 2015
    • Matt Jordan's avatar
      git migration: Refactor the ASTERISK_FILE_VERSION macro · 4a582616
      Matt Jordan authored 
      Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.

Specifically, it does the following:

* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
  remove passing the version in with the macro. Other facilities
  than 'core show file version' make use of the file names, such as
  setting a debug level only on a specific file. As such, the act of
  registering source files with the Asterisk core still has use. The
  macro rename now reflects the new macro purpose.

* main/asterisk:
  - Refactor the file_version structure to reflect that it no longer
    tracks a version field.
  - Remove the "core show file version" CLI command. Without the file
    version, it is no longer useful.
  - Remove the ast_file_version_find function. The file version is no
    longer tracked.
  - Rename ast_register_file_version/ast_unregister_file_version to
    ast_register_file/ast_unregister_file, respectively.

* main/manager: Remove value from the Version key of the ModuleCheck
  Action. The actual key itself has not been removed, as doing so would
  absolutely constitute a backwards incompatible change. However, since
  the file version is no longer tracked, there is no need to attempt to
  include it in the Version key.

* UPGRADE: Add notes for:
  - Modification to the ModuleCheck AMI Action
  - Removal of the "core show file version" CLI command

Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
      4a582616
  47. Feb 09, 2015
  49. Jul 25, 2014
  51. May 28, 2014
    • Matthew Jordan's avatar
      Logger/CLI/etc.: Fix some aesthetic issues; reduce chatty verbose messages · fb5690ce
      Matthew Jordan authored 
      This patch addresses some aesthetic issues in Asterisk. These are all just
minor tweaks to improve the look of the CLI when used in a variety of
settings. Specifically:
 * A number of chatty verbose messages were removed or demoted to DEBUG
   messages. Verbose messages with a verbosity level of 5 or higher were -
   if kept as verbose messages - demoted to level 4. Several messages
   that were emitted at verbose level 3 were demoted to 4, as announcement
   of dialplan applications being executed occur at level 3 (and so the
   effects of those applications should generally be less).
 * Some verbose messages that only appear when their respective 'debug'
   options are enabled were bumped up to always be displayed.
 * Prefix/timestamping of verbose messages were moved to the verboser
   handlers. This was done to prevent duplication of prefixes when the
   timestamp option (-T) is used with the CLI.
 * Verbose magic is removed from messages before being emitted to
   non-verboser handlers. This prevents the magic in multi-line verbose
   messages (such as SIP debug traces or the output of DumpChan) from
   being written to files.
 * _Slightly_ better support for the "light background" option (-W) was
   added. This includes using ast_term_quit in the output of XML
   documentation help, as well as changing the "Asterisk Ready" prompt to
   bright green on the default background (which stands a better chance of
   being displayed properly than bright white).

Review: https://reviewboard.asterisk.org/r/3547/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
      fb5690ce
  53. May 09, 2014
  55. Oct 14, 2012
  57. Oct 01, 2012
  59. Jul 18, 2012
  61. Jun 11, 2012
  63. May 10, 2012
  65. Apr 17, 2012
  67. Feb 27, 2012
  69. Jan 27, 2012
  71. Jul 14, 2011
  73. May 22, 2011
  75. May 03, 2011
  77. Feb 14, 2011