t...@kalik.net wrote:
When multiple threads ask for an IP at the same time it is possible for
same IP to be issued to different users. That's because allocate-find
works 10 or more times faster than allocate-update. There is a chance
that several allocate-finds will complete before first
When multiple threads ask for an IP at the same time it is possible for
same IP to be issued to different users. That's because allocate-find
works 10 or more times faster than allocate-update. There is a chance
that several allocate-finds will complete before first allocate-update
makes the
t...@kalik.net wrote:
solution :-D
You have to use a real database for that (e.g. PostgreSQL -- where
they're supported in the form of save points) ;)
I've added a note to sqlippool.conf about MySQL. This should
hopefully cut down on the problems questions.
Alan DeKok.
-
List
Dave wrote:
Can I ask what happens when the module fails ?
If the module is allocated two IP addresses to the same user, it is
failing in a big way.
My reading of the code is that it *intends* to do the queries
allocations as part of one SQL transaction. It appears, though, that
Can I ask what happens when the module fails ?
If the module is allocated two IP addresses to the same user, it is
failing in a big way.
It's the other way around. Not two IPs to the same user but same IP to
multiple users. It's a threading issue.
When multiple threads ask for an IP at the
I made this modification to the ippool.conf and still testing it, I have
not seen the issue yet again but I havent loaded the server down.
I made some other modifications to the server and database to try to
make it move as fast possible but removing
non-used modules, database indexing, other
AFAIK it is the transaction. Problem is that update will work for all
three users. Adding expiry_time IS NULL to update will cause it to work
only for the first user.
Ivan Kalik
Kalik Informatika ISP
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
My guess is it will still return an access-accept with all other
attributes accumulated minus the Framed-Ip-Address ?
Id rather it return a big fat reject, and let the NAS resend a new request?
You can configure more than one sqlippool instance. Then put as many as
you like in a fail-over
The requests all came in at the same time, to the second (among others),
its like FR took 3 requests and looked at the database at the exact same
time, saw it was an available IP and all those 3 requests assigned it.
That can't be avoided. SELECT (allocate-find) will always work much
faster than
Hello Ivan,
Would adding a mutex around the select-update code in the sqlippool
module solve this issue?
Padam
t...@kalik.net wrote:
The requests all came in at the same time, to the second (among others),
its like FR took 3 requests and looked at the database at the exact same
9:39 AM
To: FreeRadius users mailing list
Subject: Re: Handing out duplicate IP addresses
Hello Ivan,
Would adding a mutex around the select-update code in the sqlippool module
solve this issue?
Padam
t...@kalik.net wrote:
The requests all came in at the same time, to the second (among
Of *Padam J Singh
*Sent:* Thursday, January 15, 2009 9:39 AM
*To:* FreeRadius users mailing list
*Subject:* Re: Handing out duplicate IP addresses
Hello Ivan,
Would adding a mutex around the select-update code in the sqlippool
module solve this issue?
Padam
t...@kalik.net mailto:t
Can't you do the select and update as part of one transaction?
For example with MySQL:
START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summa...@a WHERE type=1;
COMMIT;
AFAIK it is the transaction. Problem is that update will work for all
three users.
[mailto:freeradius-users-bounces+ben=wisper-wireless@lists.freeradius.org]
*On Behalf Of *Padam J Singh
*Sent:* Thursday, January 15, 2009 9:39 AM
*To:* FreeRadius users mailing list
*Subject:* Re: Handing out duplicate IP addresses
Hello Ivan,
Would adding a mutex around the select
14 matches
Mail list logo
