(RADIATOR) MySQL: how to lock tables during addressallocation

Ingvar Bjarnason ingvarbj at centrum.is
Tue Sep 2 04:47:34 CDT 2003


Hi Hugh and Mike,

    Well, threads is perhaps not the proper wording here.  Multiple
instances is more like it.  We are running two radiator machines, a separate
db machine and a radiator load balancer in front.

          Radius load balancer
        auth thread - port 1645
        acct thread - port 1646

        auth thread - port 1812
        acct thread - port 1813

Both these sets of radiator instances load balance to a separate set of 6
instances ( 3 auth and 3 acct ) on each radiator machine.

I will send a separate mail outside the list with the complete config files
and a trace 4 debug.

        Best regards,
                                Ingvar


----- Original Message ----- 
From: "Hugh Irvine" <hugh at open.com.au>
To: "Ingvar Bjarnason" <ingvarbj at centrum.is>; <mikem at open.com.au>
Cc: <radiator at open.com.au>
Sent: Tuesday, September 02, 2003 3:53 AM
Subject: Re: (RADIATOR) MySQL: how to lock tables during addressallocation



Hello Ingvar -

What exactly do you mean by "multiple Radiator threads"?

I have also copied this mail to Mike for additional comments.

regards

Hugh


On Monday, Sep 1, 2003, at 22:24 Australia/Melbourne, Ingvar Bjarnason
wrote:

> Hi all,
>
>     I´m currently running into problems with <AddressAllocator SQL>.
>  When
> running multiple Radiator threads and since there is no locking taking
> place
> between the select and allocatequery the threads are "bumping" into
> each
> other selecting and trying to allocate the same ip addresses for
> different
> clients.  This significantly slows down processing.     Is there a way
> to
> make <AddressAllocator SQL> lock the tables during processing ?
>
> Here is our Addressallocator clause.
>
> <AddressAllocator SQL>
>         Identifier adsldhcpallocator
>         DBSource        dbi:mysql:radius:192.168.1.1
>         DBUsername    ******
>         DBAuth          *****
>         Timeout 10
>         FailureBackoffTime 120
>         DefaultLeasePeriod   8640000
>         LeaseReclaimInterval 8640000
>         FindQuery   select TIME_STAMP, YIADDR, SUBNETMASK, DNSSERVER
> from
> RADPOOL where POOL='%0' and STATE=0 order by TIME_STAMP LIMIT 1
>         AllocateQuery   update RADPOOL set STATE=1,TIME_STAMP=%0,
> EXPIRY=%1,
> USERNAME='%w' where YIADDR='%3' and STATE=0 and TIME_STAMP %4
>         <AddressPool ADSL>
>                 Subnetmask      255.255.255.255
>                 Range *********************
>         </AddressPool>
> </AddressAllocator>
>
>
>         Best regards,
>                                         Ingvar
>
> Ingvar Bjarnason
> Engineer
> Data Net
> Iceland Telecom
>
>
>
> ===
> 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: have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, 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.


More information about the radiator mailing list