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.
Thanks, Spencer
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.
/O
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.
Cheers, Daniel
On Monday 12 December 2011, Daniel-Constantin Mierla wrote:
On 12/10/11 11:36 AM, Olle E. Johansson wrote:
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.
How about calling an error_route block when a DB error occurs. Maybe with the proper return stack setup so the admin is able to return to the statement following the failed db query if he doesn't want to end the processing with some failure reply.
Hello,
On 12/12/11 10:46 AM, Alex Hermann wrote:
On Monday 12 December 2011, Daniel-Constantin Mierla wrote:
On 12/10/11 11:36 AM, Olle E. Johansson wrote:
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.
How about calling an error_route block when a DB error occurs. Maybe with the proper return stack setup so the admin is able to return to the statement following the failed db query if he doesn't want to end the processing with some failure reply.
this seems to need also lot of review. It may happen that functions do db operations inside locks or with some temporary states, so an eventual interruption of config file execution has to make sure that the cfg function doing the db operation finishes, to avoid deadlocks, leaks ...
Cheers, Daniel
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.
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
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.
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.
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
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 - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
-
Alex Hermann -
Daniel-Constantin Mierla -
Olle E. Johansson -
Spencer Thomason