[asterisk-bugs] [JIRA] Commented: (ASTERISK-20538) inconsistent ast_verb numbering

[Walter Doekes (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-20538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198249#comment-198249 ] 

Walter Doekes commented on ASTERISK-20538:
------------------------------------------

That would be a good explanation, if it weren't for the fact that some of these are not at all common.

I've ran verbose=20 since forever, so I did see them, but I do like to notice things like these:

{noformat}
VERBOSE[xxx] cdr_odbc.c:        > cdr_odbc: Error in ExecDirect: -1
WARNING[xxx] res_odbc.c: SQL Execute error! Verifying connection to my_database [my_database]...
WARNING[xxx] res_odbc.c: Connection is down attempting to reconnect...
NOTICE[xxx] res_odbc.c: Connecting my_database
NOTICE[xxx] res_odbc.c: res_odbc: Connected to my_database [my_database]
{noformat}

This is a CDR insertion that takes too long, after which my mysql-proxy switches over to a different database server.

This is not verbose spam, these are rare cases:

cdr/cdr_odbc.c: execute_cb(), called and retried once by ast_odbc_direct_execute.
{noformat}
        ODBC_res = SQLExecDirect(stmt, (unsigned char *)sqlcmd, SQL_NTS);

        if ((ODBC_res != SQL_SUCCESS) && (ODBC_res != SQL_SUCCESS_WITH_INFO)) {
                ast_verb(11, "cdr_odbc: Error in ExecDirect: %d\n", ODBC_res);
                SQLFreeHandle(SQL_HANDLE_STMT, stmt);
                return NULL;
        }
{noformat}

If it reconnects and succeeds, I have no way of knowing why it reconnected. If it fails after the reconnect, I only get this piece of info:
{noformat}
ast_log(LOG_ERROR, "CDR direct execute failed\n");
{noformat}

The other two instances of level 11 logging concern the module_unload. This is not something we do every couple of minutes either.

OTOH, if I look at the other modules, I do agree that those could become rather spammy.

.. I should probably change this ticket to "inconsistent ast_verb numbering in cdr_odbc" and upload a patch ;)

> inconsistent ast_verb numbering
> -------------------------------
>
>                 Key: ASTERISK-20538
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20538
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/General
>    Affects Versions: 1.8.18.0
>            Reporter: Walter Doekes
>            Severity: Trivial
>
> {noformat}
> asterisk-1.8.x$ find . -name '*.c' | xargs grep -h 'ast_verb([0-9]' | sed -e 's/.*ast_verb(//;s/,.*//' | sort | uniq -c
>     128 0
>     136 1
>       3 10
>       8 11
>     131 2
>     565 3
>      85 4
>      13 6
> {noformat}
> I.e. 3 uses of ast_verb(10) and 8 of ast_verb(11). Is there a good reason for this? Or could those calls be lowered to the 5-6 range?
> {noformat}
> asterisk-1.8.x$ find . -name '*.c' | xargs grep -l 'ast_verb(10,'
> ./cel/cel_odbc.c
> ./res/res_odbc.c
> ./cdr/cdr_adaptive_odbc.c
> {noformat}
> {noformat}
> asterisk-1.8.x$ find . -name '*.c' | xargs grep -l 'ast_verb(11,'
> ./cel/cel_odbc.c
> ./cel/cel_pgsql.c
> ./cdr/cdr_odbc.c
> ./cdr/cdr_pgsql.c
> ./cdr/cdr_adaptive_odbc.c
> {noformat}

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira