Hello,
On 09/02/16 14:05, Tim Chubb wrote:
Answer own question, re-read c docs and remember how rust my c skills are…
I think the !strncmp was throwing me, to think “if not equal to this
or that, then reconnect” rather than !strncmp being short hand for
strncmp(…)==0.
With that cleared up in my mind I’m still at a loss as to why only
have 2 out of 6 status’s deemed worthy of a reconnect attempt.
If you think more error codes should be handled in this case, make a
pull request on github to be reviewed and it will be accepted if all ok.
The unixodbc module was developed quite a while ago (like 2005), the
initial developer has been inactive for long time, so maybe some error
codes were overlooked or not available in the version at that moment.
But as usual, we are happy to accept contributions to enhance any part
of kamailio.
Cheers,
Daniel
*From:*sr-dev [mailto:sr-dev-bounces@lists.sip-router.org] *On Behalf
Of *Tim Chubb
*Sent:* 09 February 2016 12:49
*To:* Kamailio (SER) - Development Mailing List
<sr-dev(a)lists.sip-router.org>
*Subject:* [sr-dev] DB Reconnect behaviour in db_unixodbc module
Hi
Can someone explain the reasoning behind not reconnecting when an ODBC
error code of ‘08003’ or ‘08S01’ is received back in
modules/db_unixodbc/dbase.c?
Such as on lines 120 and 121?
/* Connection broken */
if( !strncmp((char*)sqlstate,"08003",5) ||
!strncmp((char*)sqlstate,"08S01",5) ) {
ret = reconnect(_h);
if( !SQL_SUCCEEDED(ret) ) return ret;
} else {
return ret;
}
Those error codes equate to Communication link failure and Connection
not open both of which are easily handled by a reconnect?
As that logic is used in a few places in dbase.c I figure there must
be a reason to exclude those errors from a reconnect, but permit other
non-connection related errors to trigger a reconnect? If the intent
was to only allow connection based error codes to attempt a reconnect
then wouldn’t it make more sense to explicitly define the half dozen
or so ODBC connection specific error codes (the 08xxx range denotes
connection related errors) and only permit the ones which could be
repaired by a reconnect?
08001 Client unable to establish connection - Can be caused by
transient network issue, so a reconnect attempt is valid
08002 Connection name in use - Reconnect probably wouldnt help here
08003 Connection not open - Reconnect would reopen connection
08004 Server rejected the connection - Can be caused by transient
network issue such as a reboot, so a reconnect attempt is valid
08007 Connection failure during transaction - Can be caused by
transient network issue, so a reconnect attempt is valid
08S01 Communication link failure - Can be caused by transient network
issue, so a reconnect attempt is valid
ODBC Error code definitions:
https://msdn.microsoft.com/en-us/library/ms714687%28v=vs.85%29.aspx?f=255&a…
Of those 6 possible connection related errors only 08002 wouldn’t be
helped by a reconnect although a new connection could replace the one
its attempting to use…
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio -
http://www.asipto.com
http://miconda.eu