5 Jun
2008
5 Jun
'08
12:30 p.m.
Hi!
The avpops module doesn't document if there's any return codes on the
database-related operations. I do hope there is, so I can figure out
if the database operation worked or not...
/O :-)
5 Jun
5 Jun
4:14 p.m.
On Thursday 05 June 2008, Johansson Olle E wrote:
The avpops module doesn't document if there's
any return codes on the
database-related operations. I do hope there is, so I can figure out
if the database operation worked or not...
Hi Olle,
have you tried it? ;-) I did a quick look to the source, it seems that '-1' is
returned if an error occured.
Cheers,
Henning
4:46 p.m.
5 jun 2008 kl. 16.14 skrev Henning Westerholt:
On Thursday 05 June 2008, Johansson Olle E wrote:
It does, I saw that too after checking the source. But the docs fail
to mention it...
/O :-)
The avpops module doesn't document if
there's any return codes on the
database-related operations. I do hope there is, so I can figure out
if the database operation worked or not...
Hi Olle,
have you tried it? ;-) I did a quick look to the source, it seems
that '-1' is
returned if an error occured.
9 Jun
9 Jun
1:40 p.m.
On Thursday 05 June 2008, Johansson Olle E wrote:
It does, I saw that too after checking the source. But the docs fail
to mention it...
Hi Olle,
i think that most functions return '-1' in case of an error, but i'm not sure
how many document this. Adding a statement to every available module function
is probably not the best way of dealing with this issue. Any idea where this
could be documented instead?
Henning
The avpops module doesn't document if there's
any return codes on the
database-related operations. I do hope there is, so I can figure out
if the database operation worked or not...
Hi Olle,
have you tried it? ;-) I did a quick look to the source, it seems
that '-1' is
returned if an error occured.
2:17 p.m.
9 jun 2008 kl. 13.40 skrev Henning Westerholt:
On Thursday 05 June 2008, Johansson Olle E wrote:
It does, I saw that too after checking the source. But the docs fail
to mention it...
Hi Olle,
i think that most functions return '-1' in case of an error, but i'm
not sure
how many document this. Adding a statement to every available module
function
is probably not the best way of dealing with this issue. Any idea
where this
could be documented instead?
That's food for thought. In this case I can imagine more error codes
though,
like -2 for database error, -1 for "not found" and other codes...
/O
The avpops module doesn't document if there's
any return codes on
the
database-related operations. I do hope there is, so I can figure
out
if the database operation worked or not...
Hi Olle,
have you tried it? ;-) I did a quick look to the source, it seems
that '-1' is
returned if an error occured.
10 Jun
10 Jun
11:22 a.m.
On Monday 09 June 2008, Johansson Olle E wrote:
Hi Olle,
sure, this is another point. But trying to agree to one scheme for error codes
for all this different module functions won't be probably easy. Why do you
think it would make sense to handle DB errors differently in the script then
any other errors? This informations are visible in the logs after all.
Henning
i think that
most functions return '-1' in case of an error, but i'm
not sure how many document this. Adding a statement to every available
module functionis probably not the best way of dealing with this issue.
Any idea where this could be documented instead?
That's food for thought. In this case I can imagine more error codes
though, like -2 for database error, -1 for "not found" and other codes...
1:26 p.m.
10 jun 2008 kl. 11.22 skrev Henning Westerholt:
On Monday 09 June 2008, Johansson Olle E wrote:
Hi Olle,
sure, this is another point. But trying to agree to one scheme for
error codes
for all this different module functions won't be probably easy. Why
do you
think it would make sense to handle DB errors differently in the
script then
any other errors? This informations are visible in the logs after all.
Well, there's a big difference if we have a negative reply from the
database
or no reply at all from the database because it's down. In general,
I'm wondering
how to catch that state in the Openser config without reading log
files - maybe
the error_route could catch these so I could send a warning somewhere.
That would be generic enough and handled from the db subsystem.
We already have apps that return various error codes that are
"reserved",
like the auth functions and the t_relay function.
/O
i think
that most functions return '-1' in case of an error, but i'm
not sure how many document this. Adding a statement to every
available
module functionis probably not the best way of dealing with this
issue.
Any idea where this could be documented instead?
That's food for thought. In this case I can imagine more error codes
though, like -2 for database error, -1 for "not found" and other
codes...
11 Jun
11 Jun
3:37 p.m.
On Tuesday 10 June 2008, Johansson Olle E wrote:
Well, there's a big difference if we have a
negative reply from the
database or no reply at all from the database because it's down. In general,
I'm wondering how to catch that state in the Openser config without reading
log files - maybe the error_route could catch these so I could send a
warning somewhere. That would be generic enough and handled from the db
subsystem.
We already have apps that return various error codes that are
"reserved", like the auth functions and the t_relay function.
Hi Olle,
i agree, this would be for the avpops module functions that work directly with
a DB good thing. For other modules that also depend on DB operations this is
probably quite a bunch of work, and needs to discussed on devel after the
release.
But i don't think its a good idea to handle the state of server dependencies
through OpenSER. This should be IMHO done with some external monitoring
applications.
Henning
4:33 p.m.
11 jun 2008 kl. 15.37 skrev Henning Westerholt:
On Tuesday 10 June 2008, Johansson Olle E wrote:
None of this is critical for the release - frozen or not.
We need to have a clear handling of Database failures - disconnects
and reconnects.
/O
Well, there's a big difference if we have a
negative reply from the
database or no reply at all from the database because it's down. In
general,
I'm wondering how to catch that state in the Openser config without
reading
log files - maybe the error_route could catch these so I could send a
warning somewhere. That would be generic enough and handled from
the db
subsystem.
We already have apps that return various error codes that are
"reserved", like the auth functions and the t_relay function.
Hi Olle,
i agree, this would be for the avpops module functions that work
directly with
a DB good thing. For other modules that also depend on DB operations
this is
probably quite a bunch of work, and needs to discussed on devel
after the
release.
But i don't think its a good idea to handle the state of server
dependencies
through OpenSER. This should be IMHO done with some external
monitoring
applications.
4:45 p.m.
On Wednesday 11 June 2008, Johansson Olle E wrote:
None of this is critical for the release - frozen or
not.
We need to have a clear handling of Database failures - disconnects
and reconnects.
Ack. :-) Lets discuss this again when 1.4 was released, i already have some
ideas.
Regards,
Henning
5791
days inactive
5797
days old
9 comments
2 participants
participants (2)
-
Henning Westerholt -
Johansson Olle E