(RADIATOR) SQL Timeout vs SQL "Could not Connect"

[Hugh Irvine]

Hello Chris -

Could you please clarify what you mean by "shuts down immediately"?

And could you also please send me all the details regarding 
hardware/software platform, versions of Perl, DBI, DBD, Oracle, etc. 
Radiator should back off from the database for the specified time and 
then try to reconnect.

regards

Hugh


On Monday, October 21, 2002, at 10:33 PM, Chris Cronje wrote:

> Hi There
>
> (Radiator 3.3.1)
> I have a question about the Timeout and FailureBackoffTime settings 
> used for SQL connections. Specifically for the Sessiondatabase 
> configuration I am using below:
>
> <SessionDatabase SQL>
>         DBSource        dbi:Oracle:TEST
>         DBUsername      radiator
>         DBAuth          radiator
>         Timeout 3
>         FailureBackoffTime 60
> </SessionDatabase>
>
>
>
> If there is no existing SQL connection and Radiator cannot connect to 
> the SQL Database at all, a "Could not connect" message is generated 
> and Radiator backs off for 60 seconds as specified:
>
>
>
> Mon Oct 21 14:09:50 2002: DEBUG: Packet dump:
> *** Received from 196.2.129.13 port 1572 ....
> Code:       Access-Request
> Identifier: 0
> Authentic:        1035202501
> Attributes:
>         User-Name = "modtest"
>         User-Password = "Z?<201>1<188><142>+<159>c<190>O+<21>M<180>t"
>
> Mon Oct 21 14:09:50 2002: DEBUG: Handling request with Handler 'Realm='
> Mon Oct 21 14:09:53 2002: ERR: Could not connect to SQL database with 
> DBI->connect dbi:Oracle:TEST, radiator, radiator: timeout at 
> /usr/lib/perl5/site_perl/5.6.1/Radius/Util.pm line 519.
>
> Mon Oct 21 14:09:53 2002: ERR: Could not connect to any SQL database. 
> Request is ignored. Backing off for 60 seconds
>
>
>
>
> If there is an existing SQL session and a network failure occurs, 
> Radiator generates an "SQL Timeout" message, as opposed to the "Could 
> not connect" from above. In this case, Radiator does not seem to do 
> the Failure Backoff, in fact it actually shuts down immediately after 
> the SQL Timeout error:
>
>
>
>
> Mon Oct 21 14:11:19 2002: DEBUG: Packet dump:
> *** Received from 196.2.129.13 port 1582 ....
> Code:       Access-Request
> Identifier: 10
> Authentic:        1035202591
> Attributes:
>         User-Name = "modtest"
>         User-Password = 
> "{<225>.<213><171>y<223><175><249><24>d<7>)<135><130>/"
>
> Mon Oct 21 14:11:19 2002: DEBUG: Handling request with Handler 'Realm='
> Mon Oct 21 14:11:19 2002: DEBUG:  Deleting session for modtest, 
> 196.2.129.13,
> Mon Oct 21 14:11:19 2002: DEBUG: do query is: delete from RADONLINE 
> where NASIDENTIFIER='196.2.129.13' and NASPORT=0
>
> Mon Oct 21 14:11:22 2002: ERR: do failed for 'delete from RADONLINE 
> where NASIDENTIFIER='196.2.129.13' and NASPORT=0': SQL Timeout
>
>
>
> Is this the way it is supposed to be or should the FailureBackoffTime 
> work for both "Could Not Connect" and "SQL Timeout" conditions ?
>
>
>
> Kind Regards
>
> Chris Cronje
>  
> Give your child an unfair advantage with M-Web Learning.  To join, 
> call 08600 32 000 or go to http://join.mweb.co.za
>
> M-Web – JUST LIKE THAT
> ===
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.
>
>

NB: I am travelling this week, so there may be delays in our 
correspondence.

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.

===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.