12 dec 2011 kl. 11:26 skrev Daniel-Constantin Mierla: > Hello, > > On 12/12/11 10:49 AM, Olle E. Johansson wrote: >> 12 dec 2011 kl. 10:33 skrev Daniel-Constantin Mierla: >> >>> Hello, >>> >>> On 12/10/11 11:36 AM, Olle E. Johansson wrote: >>>> 9 dec 2011 kl. 18:54 skrev Spencer Thomason: >>>> >>>>> Hello all, >>>>> Is it possible to configure Kamailio to reply to a request with a 503 if >>>>> it cannot connect to a necessary database for the operation? >>>>> >>>>> I.e. Kamailio cannot connect to the database, when a REGISTER comes in >>>>> and userloc can't find the credentials (due to DB failure), respond with >>>>> a 503. The requesting endpoint can then fail over properly. The same >>>>> behaviour would be desired for other modules as well, i.e. aliasdb. >>>>> >>>>> >>>>> I noticed using 3.1.5 that it simply does not authorize the user. >>>>> >>>>> >>>> I have been thinking about this as well. We could implement a db_ping >>>> function so we could test in the routing script before >>>> calling functions that use the DB. It's harder with stuff that happens in >>>> the background, like ACC and SIPTRACE. I don't know >>>> what happens with them if the database fails. >>> one option would be to set a config env variable, like db_error, which is >>> set by the db modules on error. Then can be checked in the config and act >>> accordingly. This will require touching the db modules. >>> >>> Alternative is to propagate some return codes up to config file, but this >>> will require changes in all modules interacting with database, including >>> the db modules. >> Great. I think a db_ping which forces a test, a db_status variable that >> shows the result of the last database operation is a good start. > yes, db_ping() is good for interaction from config file. I thought of > db_status more for the other functions that use db behind (like auth_db). > > I wonder if each sql server has this ping capability -- mysql lib offers > mysql_ping() (which is used in db_mysql module), iirc, postgress has as well > although not used in db_postgres (afaik). If all, ping function may be > exported via db interface and offered to config from sqlops, where is easy to > provide connection id. I'm sure there's one way or another to implement a ping. Just query for something non-important and make sure you get some kind of response.
> > When ping is not offered by library, then maybe never fail query like 'select > count(*) from version' can be used - this should be usable even now with > sqlops. Exactly. If I take it right we can start with implementing something in the db layer. After that implement it in the db drivers. If the driver doesn't support it, we need a response code saying "Not yet supported by db driver". /O > > Cheers, > Daniel > >> >> The return code stuff is a more long term issue. I'll try to allocate time >> to see if I can get somewhere with these two. If I need help, this list will >> now :-) >> >> /O >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users@lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > > -- > Daniel-Constantin Mierla -- http://www.asipto.com > http://linkedin.com/in/miconda -- http://twitter.com/miconda --- * Olle E Johansson - o...@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
