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 :-)
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
5 jun 2008 kl. 16.14 skrev Henning Westerholt:
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.
It does, I saw that too after checking the source. But the docs fail to mention it...
/O :-)
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.
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
9 jun 2008 kl. 13.40 skrev Henning Westerholt:
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.
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
On Monday 09 June 2008, Johansson Olle E wrote:
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...
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
10 jun 2008 kl. 11.22 skrev Henning Westerholt:
On Monday 09 June 2008, Johansson Olle E wrote:
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...
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
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
11 jun 2008 kl. 15.37 skrev Henning Westerholt:
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.
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
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
-
Henning Westerholt -
Johansson Olle E