Re: [Catalyst] Book
On Mon, 25 Feb 2008 14:09:07 + Dermot [EMAIL PROTECTED] wrote: snip What does the list think about the books. I can also heartily recommend this book. I've read through it once -- something I do with all computer books before I work through the examples -- and that alone cleared up quite a few of my questions. -- Xelia Wizard Systems Inc Kevin Nathan 1220 S. Park Lane Ste. 3 Tempe, AZ 85281 (480) 516-0710 [EMAIL PROTECTED] [EMAIL PROTECTED] NOTICE: This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete and destroy all copies. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Database connections leaking
On Mon, 24 Dec 2007 18:22:13 + Matt S Trout [EMAIL PROTECTED] wrote: You might want to see about ripping out the C::M::DBI connection management and using a DBIx::Class::Storage::DBI object instead - the Model::DBI code originates from a copy of the DBIx::Class code but I'm unaware of whether bugfixes and refactorings have been propagated to it. That's basically what I ended up doing. I didn't like having two files that each had a db connection setup; since all of our tables are DBIx::Class, I got rid of the C::M::DBI and did some more searching on my problem (wanting to do straight SQL from legacy code). Found exactly what I needed in an excerpt from Jonathan Rockway's new book (my copy has been on order for almost a week now and can't wait to get it!) For those of you interested in this solution, see: http://www.packtpub.com/article/catalyst-web-framework-building-your-own-model and the section titled 'Extending a DBIx::Class Model'. It took a few days to modify all the legacy code and get it running, but it's nice having it a bit 'cleaner'. Unfortunately, still have db connection leaking so the sysadmin is checking the Apache/mod_perl side (this is beyond me at this point). I would like to thank everyone for their help and suggestions -- I would have stumbled a lot longer without your help. :-) -- Xelia Wizard Systems Inc Kevin Nathan 1220 S. Park Lane Ste. 3 Tempe, AZ 85281 (480) 516-0710 [EMAIL PROTECTED] [EMAIL PROTECTED] NOTICE: This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete and destroy all copies. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Database connections leaking
On Sat, 22 Dec 2007 13:32:00 +1030 Jon Schutz [EMAIL PROTECTED] wrote: On Fri, 2007-12-21 at 18:34 -0700, [EMAIL PROTECTED] wrote: The program seems to be working fine while on the Catalyst test server, and when on an Apache/mod_perl server when the postgres database is on the same physical server. The database connections don't start leaking until we attempt to use a separate (physical) database server. We verified this using iptraf and seeing none of the connections being re-used *or* closed. How many database connections are you actually seeing? You should expect up to one per Apache/mod_perl process. Are you also seeing growth in the number of Apache processes? I can't check the server right now (need to be at work for that), but I didn't think to watch for Apache/mod_perl processes. What we were looking for was port 5432 connections (postgres). When it works, we get two or three connections per login and they stay steady. When it's not working, they continuously increase until config limit is reached (we've gone as high as 3000 connections). It will be a few days now, before I can check it again unless I get some time to drive to the colocation, but I will check for the Apache processes. If they are going up, too, where should I look? Any hints (or websites) that may help? Thanks for the quick response! -- Kevin Nathan (Arizona, USA) [EMAIL PROTECTED] Open standards. Open source. Open minds. The command line is the front line. Linux 2.6.16.27-0.9-default 9:29pm up 7:40, 18 users, load average: 0.27, 0.25, 0.35 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Database connections leaking
On Sat, 22 Dec 2007 15:34:14 +1030 Jon Schutz [EMAIL PROTECTED] wrote: It seems to me you would know about it, one way or another, if you had 3000 apache processes! It would seem so, wouldn't it? :-) From what I remember, though, we never saw a real increase in port 443 connections. I would speculate that the logic in Catalyst::Model::DBI that checks whether it currently has an active connection, is not working for remote Postgres connections, so it keeps creating new ones. That makes sense. I even looked at C::M::DBI, quite a bit, but it just didn't make it through all my hair-pulling . . . I suggest (a) making sure you have the latest version of DBI and DBD::pg and postgres libraries, I will do that tomorrow, although I'm pretty sure they're fairly current -- the servers were just built a few weeks ago (Gentoo, from scratch). and if that doesn't solve it, (b) add debug into Catalyst::Model::DBI stay_connected sub to find out which bit of the logic is causing a reconnect. See? Now *that's* what I should have realized! ;-) Even after looking at that code, it didn't occur to me to add the debug code; of course, I have debug code all over everything else. Looks like I will be driving in to work tomorrow . . . As I'm not much of a postgres or mod_perl user, I bow out here and let the experts take over... Well, I would like to thank you profusely. You've at least helped clear the cobwebs away from my overworked brain cell and given me a bit of hope that I'm not entirely out of my depth -- close, but not completely, yet! :-) Thanks, again. -- Kevin Nathan (Arizona, USA) [EMAIL PROTECTED] Open standards. Open source. Open minds. The command line is the front line. Linux 2.6.16.27-0.9-default 12:08am up 10:19, 18 users, load average: 0.33, 1.06, 1.65 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/