9 Dec
2011
9 Dec
'11
12:54 p.m.
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
10 Dec
10 Dec
5:36 a.m.
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
12 Dec
12 Dec
4:33 a.m.
Hello,
On 12/10/11 11:36 AM, Olle E. Johansson wrote:
9 dec 2011 kl. 18:54 skrev Spencer Thomason:
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
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
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. 
4:46 a.m.
On Monday 12 December 2011, Daniel-Constantin Mierla wrote:
On 12/10/11 11:36 AM, Olle E. Johansson wrote:
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.
--
Greetings,
Alex Hermann
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.
5:32 a.m.
Hello,
On 12/12/11 10:46 AM, Alex Hermann wrote:
On Monday 12 December 2011, Daniel-Constantin Mierla
wrote:
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
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
On 12/10/11 11:36 AM, Olle E. Johansson wrote:
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.
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.
4:49 a.m.
12 dec 2011 kl. 10:33 skrev Daniel-Constantin Mierla:
Hello,
On 12/10/11 11:36 AM, Olle E. Johansson wrote:
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
9 dec 2011 kl. 18:54 skrev Spencer Thomason:
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. 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.
5:26 a.m.
Hello,
On 12/12/11 10:49 AM, Olle E. Johansson wrote:
12 dec 2011 kl. 10:33 skrev Daniel-Constantin Mierla:
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
Hello,
On 12/10/11 11:36 AM, Olle E. Johansson wrote:
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. 9 dec 2011 kl. 18:54 skrev Spencer Thomason:
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. 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.
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(a)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
5:31 a.m.
12 dec 2011 kl. 11:26 skrev Daniel-Constantin Mierla:
Hello,
On 12/12/11 10:49 AM, Olle E. Johansson wrote:
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.
12 dec 2011 kl. 10:33 skrev Daniel-Constantin
Mierla:
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. Hello,
On 12/10/11 11:36 AM, Olle E. Johansson wrote:
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. 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.
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
---
* Olle E Johansson - oej(a)edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden
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(a)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
4777
days inactive
4780
days old
7 comments
4 participants
participants (4)
-
Alex Hermann -
Daniel-Constantin Mierla -
Olle E. Johansson -
Spencer Thomason