26 Sep
2004
26 Sep
'04
11:44 p.m.
On Sep 26, 2004, at 1:56 PM, Michael Shuler wrote:
I figured that's what people would say :( thanks
though.
I thought of that but the problem is that it takes up to the max time
of my
longest REGISTER client timer before its back in sync with the one
that runs
off the DB. It would be nice if there was a 3rd option i.e.
modparam("usrloc", "db_mode", 3) that would make it read only at
startup to
"seed" the memory database. The reason I need this is because I have
a few
SER servers behind a Foundry ServerIron XL layer 4 switch. When I
bring the
failed server back online the Foundry automatically recognizes that
port
5060 is alive again and immediately starts sending it traffic. If the
RAM
based location table hasn't been fully populated by the time this
happens
then we have a bunch of failed calls until it syncs up which in my
case is
up to 5 min. I can get around this manually by removing it from the
cluster
config in the Foundry but that takes away from the automation of the
whole
thing.
I've suggested a similar idea in the past. I'd like to see the
database queried
every time a request comes in, or, any time a request comes in and the
'ram'
database doesn't have a result. That way you could run more than one
ser process on a single database instance.
-g
Andrei/Jiri, what do you guys think of adding that as an option? It
seems
to me that it would be the most logical way to go about doing it and
should
be very easy to do since all it is combining parts of mode 0 and 1/2.
I
have little experience doing any programming in SER otherwise I would
just
write it and submit it as a patch. Most of my time gets sucked up into
Asterisk patches (see http://svn.asteriskdocs.org/res_data/ for MySQL
dynamic config files, this is a must for carriers... Well at least for
me :)
), but if you 2 don't have time or don't think its worth while then I
guess
I will have find time. Please let me know what you guys think of this
as
soon as you get a chance.
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
Greg Fausak
www.AddaBrand.com
(US) 469-546-1265
-----Original Message-----
From: Maxim Sobolev [mailto:sobomax@portaone.com]
Sent: Sunday, September 26, 2004 3:28 AM
To: Michael Shuler
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Location table issues
Michael Shuler wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Let's say I have 2 SER servers (ser1 and
ser2). Both save
to the same MySQL
location table and both use t_replicate to let
each other
know about new
REGISTER's. Lets say ser1 gets a REGISTER
from a client
and then calls
t_replicate to send it over to ser2 and both call
save("location"). Doesn't
that cause ser1 and ser2 to write the same record
at about
the same time to
MySQL? Is there any way to prevent doubling the
number of
database writes?
You can configure one of the ser's to do not use database at all for
storing contacts, which will do what you want - contacts will
be saved
by the another ser, while t_replicate() will ensure that both of them
have a whole set at any moment of time.
-Maxim
Does anyone know what the replicate column is for in the
location table?
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers