After reading the post by Michal, I would suggest you a little effort on trying the following: move the database to the local machine. Anyway you probably going to tell me that's not possible and other stuff, but think about the following scenario: A database on the local machine, replicating to the remote site, asynchronally, this way it will not hang up trying to "commit" the tables on both sites, so you get fast response on accounting and the database will carry itself handling the replication over the slow link. That might solve your problem, worth a try. Btw, which database you using? -----Original Message----- From: openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Edson Sent: Thursday, August 03, 2006 3:29 PM To: 'GNU Gatekeeper Users' Subject: Re: Controlling Threads Hi, Michal... That is not clear for me why You wouldn't increase MinPoolSize... as far as I understand, the problem arises when the load grows (cps or active calls), and, in my case that BD is on a remote site/machine, the time for SQL operations grows too, as a side effect. So the problem is narrow to the leak of available SQL connections on the pool (all are busy waiting for the end of some SQL operation). If this assumption on the problem is correct, then, again, why is the MinPoolSize not a good solution/workaround? Where are the drawbacks? Which other problems arise from this change? Calls tend to have a greater delay? I agree that controlling the maximum number of TCP connections isn't a good approach, since they didn't offer any kind of interconnection with GK work logic... Edson. > -----Original Message----- > From: openh323gk-users-bounces@xxxxxxxxxxxxxxxxxxxxx [mailto:openh323gk- > users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of Zygmuntowicz Michal > Sent: quinta-feira, 3 de agosto de 2006 11:51 > To: GNU Gatekeeper Users > Subject: Re: Controlling Threads > > I'd rather not increase number of SQL connection - this does not solve > the problem - just makes it less noticeable. > Under high load new calls should be rejected, but this is not so simple > - we have to wait a bit before a new call is rejected (some timeout). > If there exists some timeout - you will always find some CPS value, > that will block the system. The only solution would be to set a hard limit > for TCP connections/calls and reject new call attempts as soon as > possible. > But then you will loose CDRs.. > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/ Esta mensagem foi verificada pelo E-mail Protegido Terra. Scan engine: McAfee VirusScan / Atualizado em 03/08/2006 / Versco: 4.4.00/4821 Proteja o seu e-mail Terra: http://mail.terra.com.br/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________________ Posting: mailto:Openh323gk-users@xxxxxxxxxxxxxxxxxxxxx Archive: http://sourceforge.net/mailarchive/forum.php?forum_id=8549 Unsubscribe: http://lists.sourceforge.net/lists/listinfo/openh323gk-users Homepage: http://www.gnugk.org/
