Re: [RadiusNT] Status of our question????

Mike Miller ( michael@abraxis.com )
Fri, 12 Mar 1999 13:30:54 -0500

Dale,

I think (but am not positive yet) that we have the concurrency problems
under control. We moved Radius onto a different machine than the SQL
server and the concurrency problems seem to have gone away??? Even still
we have problems with insert queries locking the calls table if we shut
down Radius. It appears however, that these locks do go away with a reboot
of the SQL machine (unlike when Radius was on the same machine as SQL and
the locks would still be there). The problem is fully reproducible.. and
makes no sense that moving Radius to a machine other than the SQL box
changed the problems in such a strange way. Has the RadiusNT/SQL 7 combo
been tested in a multi-processor capable environment? I ask because our
SQL box was showing long spikes of 100% CPU usage when Radius was running
on the same box (we discovered this this morning). Radius debug was not
showing slow response times despite the spikes in CPU usage.

To answer your question... we have tried this on a fresh install of NT,
SP4, and SQL 7 on this same machine, but we have not tried it on other
hardware. I would agree with you about the possibility of a SQL install
problem, but... at the moment all fingers are pointed at Radius (the
processes causing locks are started by Radius, and Radius don't seem to
like running on the same box as SQL 7)

Taking questions one at a time... how does Radius/SQL handle it, when
Radius is shut down (what is causing our calls table to get locked)? How
(if any) does this differ from connecting to a SQL 6.5 database? We are
using a system DSN via TCP/IP sockets to connect Radius to the SQL
database. The hardware our SQL server is using is PII-333, 256MB RAM. The
data portion of our database size is about 600MB on a properly populated
Calls table (but is much smaller now because we have dropped our calls
accounting history during these problems). If we can get these questions
about why Radius is causing locks in our calls table, then we can take the
appropriate steps to stop it from happening.

Further data:

ODBC version on system where Radius
concurrency works: 3.50.0305
(Locks on Calls table from this Radius can be cleared
with a reboot of the SQL box)

ODBC version on system where Radius concurrency
doesn't work (SQL 7 box): 3.70.06.23
(Locks on Calls table from this Radius can not be cleared
with a reboot of the SQL box)

--At 10:06 AM 3/12/99 -0800, you wrote:>Mike Miller wrote:>> >> We are still having severe problems with RadiusNT 2.5 and SQL 7.0... I am>> still waiting on a response to our last e-mail.  Now another problem has>> developed... concurrency control is not working properly at all even when>> calls are properly getting inserted into the calls table.  Random people,>> several hundred per day, are getting reported as online in the CallsOnline>> view, but are really no longer online at all.  We have pretty much come to>> the conclusion that RadiusNT 2.5 simply does not work with SQL 7.0 because>> if we point our DSN back to our old SQL 6.5 database everything works>> perfectly (unfortunately that datasource is not a week and a half behind in>> data because all our new data [or a portion thereof] is in the new SQL 7.0>> database)!  The lack of response from Dale makes us wonder if Radius is>> even is compatible at all.  Please respond soon Dale.. we need a fix tothis.>>We have several customers using RadiusNT 2.5 and SQL 7.0.  I myself ONLY>use SQL 7.0 for development now and do not know of any problems between>it and RadiusNT.  I *DO* know of many problems of it crashing and ways>to make it stop responding, etc.  They are not things that RadiusNT >typically uses, though.>>Could it be that you have a configuration problem with your SQL 7>install?>Do you have another SQL 7 server that you can test with?>>-- >>Dale E. Reed Jr.      Emerald and RadiusNT>__________________________________________>IEA Software, Inc.    www.iea-software.com>>For more information about this list, including removal, please>see this URL: http://www.iea-software.com/maillist.html > ====================================================  /\                          Mike A. Miller     == /--\         \/              Abraxis Networks   ==/    \ B R A  /\ I S                             ==             /                                   ==      N E T W O R K S         michael@abraxis.com====================================================

For more information about this list, including removal, pleasesee this URL: http://www.iea-software.com/maillist.html