Re: DBI Connectons accumulate under Mod_perl

[Artem Kuchin]

Kulasekaran, Raja:

It's like each child process create a new database process and it
remains stable. Instead of establishing a database connection, there is
a possibility to share the connection between the child threads using
sqlrelay (http://sqlrelay.sourceforge.net/ ). But I have no idea about
sqlrelay.

Is this issue resolved in Mod_perl 2.0? . I have read the article
"DB::Pool". Can anyone help me out on this.


  


You mean each child process creates a new database CONNECTION (not 
process) ?
The process is just one multhreaded mysql. But this is exactly what i 
want. I do not want any
connection sharing because of the locking issues (lock tables). But they 
still accumulate and after a
couple of hours mysql runs out of connections. The weirdest thing is 
that there are two sites, running
pretty much the same software (minor changes to user part, no changes to 
db part). Connections
from one site accumulate, connection from other site do not accmulate - 
disconnect work fine.




-Original Message-
From: Artem Kuchin [mailto:mat...@itlegion.ru] 
Sent: Tuesday, October 20, 2009 10:29 PM

To: modperl@perl.apache.org
Subject: DBI Connectons accumulate under Mod_perl

Hello!

I have a very weird situation. I use MYSQL. Apache 2.2 with mod_perl2

O use Modperl::RegistryBB to run the script, but the script itself is
written very nicely
for mod_perl. That is no globals at all. Everything is in sub handler.
I do not use Apache::DBI, just plain "use DBI;"

So, what it does (basic idea)

sub  handler {
db->connect();

.. does all the thing...

db->disconnect();

print $output;

}

however, whe i do in mysql

show processlist;

I see many connection hanging in sleep state and they grow and grow
slowly!
Any idea why this happens?

Artem



  


--
С уважением,
Артем Кучин
Компания "Ай Ти Легион"
www.itlegion.ru
www.hostilla.ru
+7 (495) 232-0338

Re: DBI Connectons accumulate under Mod_perl

[David E. Wheeler]

On Nov 10, 2009, at 7:04 AM, Artem Kuchin wrote:

> You mean each child process creates a new database CONNECTION (not process) ?
> The process is just one multhreaded mysql. But this is exactly what i want. I 
> do not want any
> connection sharing because of the locking issues (lock tables). But they 
> still accumulate and after a
> couple of hours mysql runs out of connections. The weirdest thing is that 
> there are two sites, running
> pretty much the same software (minor changes to user part, no changes to db 
> part). Connections
> from one site accumulate, connection from other site do not accmulate - 
> disconnect work fine.

Might you have connections starting in parent processes and not getting 
dropped? Are you using Apache::DBI or DBI->connect_cached or DBIx::Connector?

Best,

David

RE: DBI Connectons accumulate under Mod_perl

[Kulasekaran, Raja]

I'm using Apache::DBI and DBI->connect (persistence connection) 

So, Do I need to call $dbh->disconnect() for each child to close the
connection ?

Raja . 


-Original Message-
From: David E. Wheeler [mailto:da...@kineticode.com] 
Sent: Tuesday, November 10, 2009 10:43 PM
To: Artem Kuchin
Cc: Kulasekaran, Raja; modperl@perl.apache.org
Subject: Re: DBI Connectons accumulate under Mod_perl

On Nov 10, 2009, at 7:04 AM, Artem Kuchin wrote:

> You mean each child process creates a new database CONNECTION (not
process) ?
> The process is just one multhreaded mysql. But this is exactly what i
want. I do not want any
> connection sharing because of the locking issues (lock tables). But
they still accumulate and after a
> couple of hours mysql runs out of connections. The weirdest thing is
that there are two sites, running
> pretty much the same software (minor changes to user part, no changes
to db part). Connections
> from one site accumulate, connection from other site do not accmulate
- disconnect work fine.

Might you have connections starting in parent processes and not getting
dropped? Are you using Apache::DBI or DBI->connect_cached or
DBIx::Connector?

Best,

David

Re: DBI Connectons accumulate under Mod_perl

[David E. Wheeler]

On Nov 10, 2009, at 9:19 AM, Kulasekaran, Raja wrote:

> I'm using Apache::DBI and DBI->connect (persistence connection) 
> 
> So, Do I need to call $dbh->disconnect() for each child to close the
> connection ?

No, because Apache::DBI turns it into a no-op.

Apache::DBI is a very weird beast, with unanticipated action-at-a-distance 
issues that crop up here and there. It's crazy stuff like this that led me to 
abandon it -- at first for DBI->connect_cached (though I had to do some extra 
work to make sure it was safe), and more recently for DBIx::Connector, which 
does that extra work for me.

Can you see what PIDs MySQL is accepting connections from? Are they the same as 
currently-running Apache processes? Or are (some of them) from dead Apache 
child processes?

Best,

David

Re: FreeBSD 7.2, mod_perl2 & Apache2::Cookie (libapreq2)

[Foo JH]

Hello Joe,

Do you think you can post the changes that need to be made here, for us 
to reference when we hit the same problem?


Thanks.

Joe Niederberger wrote:

Thanks to everyone who contributed their insights to this thread - I
did get in touch with Mr. Galucci - and he did help straighten out
my installation. The main problem here was some remnants of Apache2
were still in the file system and lib pointers were not set correctly 
during

the install and so things didn't link up properly.
 
Thanks again,

Joe Niederberger

- Original Message -
*From:* macke...@animalhead.com 
*To:* Sin 
*Cc:* metacyc...@gmail.com  ;
mod_perl list 
*Sent:* Friday, October 30, 2009 11:56 AM
*Subject:* Re: FreeBSD 7.2, mod_perl2 & Apache2::Cookie (libapreq2)

The man you want at the FreeBSD lists is Philip M. Gollucci.  
He maintains libapreq2 in the ports collection, and was very
helpful to me when I was trying to get the module to build, 
earlier this year.


Good Luck and please report your results to this list when this is
settled,
cmac


On Oct 30, 2009, at 9:44 AM, Sin wrote:


When I build from ports the " make config " usually brings up a
window that has options for both 32 bit and 64 bit.   If I had to
guess I'd say its the same Makefile and source code that builds
the binary files.   Or in your case a 64 bit bin file.   But
honestly I really don't know, we should steer this thread over to
the FreeBSD mailling lists.  Perhaps its just a matter of
pointing this out to a maintainer or the governing group at the
FreeBSD mailling list people.   Maybe they know the next step? 


- Original Message -
*From:* metacyc...@gmail.com 
*To:* Sin 
*Cc:* Foo JH  ; Adam Prime
 ; Joe Niederberger
 ; mod_perl list

*Sent:* Friday, October 30, 2009 12:36 PM
*Subject:* Re: FreeBSD 7.2, mod_perl2 & Apache2::Cookie
(libapreq2)

This may be completely unrelated, but I had similar headaches
installing libapreq2 on a 64 bit machine that had both 32 and
64 bit libs installed.  I had to uninstall the offending 32
bit libs (which I didn't need).

Do they have a similar setup?

Dimitri

On Fri, Oct 30, 2009 at 12:28 PM, Sin mailto:sinis...@gmail.com>> wrote:

pkg_add -r just goes to a package repository and gets a
package version thats allready complied for your
distribution.   So you can't build your options.

However this apreq2.12 issue is interesting.   I was
going to try this again.   I went to build this port but
make errored out with:

===>  libapreq2-2.12_1 : Error from bsd.apache.mk
. apache13 is installed (or
APACHE_PORT is defined) and port requires 2.0+.
*** Error code 1


But if you look at the port it says apache-1.3.41_1 is
the build and run dependency.  So it should of built the
port (because I just happen to have apache 1.3 installed
).   I'm wondering if all the times I tried to build
Apache2.x with mod_perl2 the application couldn't
interface with it because of a missing dependency.


I'm not a BSD expert but it looks like this port needs
updating.   Here's the description in ports:



Port:   libapreq2-2.12_1
Path:   /usr/ports/www/libapreq2
Info:   Generic Apache2 Request Library
Maint:  s...@freebsd.org 

B-deps: apache-1.3.41_1 autoconf-2.62
autoconf-wrapper-20071109 expat-2.0.1 gettext-0.17_1
gmake-3.81_3 libiconv-1.13.1 libtool-2.2.6a_1 m4-1.4.13,1
perl-5.8.9_3

R-deps: apache-1.3.41_1 expat-2.0.1 perl-5.8.9_3
WWW:http://httpd.apache.org/apreq/



Port:   p5-libapreq2-2.12_1
Path:   /usr/ports/www/p5-libapreq2
Info:   Generic Apache2 Request Library
Maint:  s...@freebsd.org 

B-deps: apache-1.3.41_1 autoconf-2.62
autoconf-wrapper-20071109 expat-2.0.1 gettext-0.17_1
gmake-3.81_3 libiconv-1.13.1 libtool-2.2.6a_1 m4-1.4.13,1
mod_perl2-2.0.4_2,3 p5-BSD-Resource-1.2903
p5-ExtUtils-XSBuilder-0.28_1 p5-Parse-RecDescent-1.962.2
p5-Tie-IxHash-1.21 p5-version-0.76 perl-5.8.9_3

R-deps: apache-1.3.41_1 expat-2.0.1 mod_perl2-2.0.4_2,3
p5-BSD-R

Re: FreeBSD 7.2, mod_perl2 & Apache2::Cookie (libapreq2)

[Joe Niederberger]

Well, I didn't make the changes myself - they were done by Datapipe staff
who
run a server for me. The route taken was extreme - they basically
de-installed all packages
and reinstalled. There may be better ways to go about it.

Joe N.

- Original Message - 
From: "Foo JH" 
To: "Joe Niederberger" 
Cc: ; "mod_perl list" 
Sent: Tuesday, November 10, 2009 8:41 PM
Subject: Re: FreeBSD 7.2, mod_perl2 & Apache2::Cookie (libapreq2)


> Hello Joe,
>
> Do you think you can post the changes that need to be made here, for us
> to reference when we hit the same problem?
>
> Thanks.

RE: DBI Connectons accumulate under Mod_perl

[Kulasekaran, Raja]

I'm connecting against oracle. So for every request it establish the
connection and it remains stable even though the request 
has been completed successfully . 

-Raja 

-Original Message-
From: David E. Wheeler [mailto:da...@kineticode.com] 
Sent: Tuesday, November 10, 2009 11:03 PM
To: Kulasekaran, Raja
Cc: Artem Kuchin; modperl@perl.apache.org
Subject: Re: DBI Connectons accumulate under Mod_perl

On Nov 10, 2009, at 9:19 AM, Kulasekaran, Raja wrote:

> I'm using Apache::DBI and DBI->connect (persistence connection) 
> 
> So, Do I need to call $dbh->disconnect() for each child to close the
> connection ?

No, because Apache::DBI turns it into a no-op.

Apache::DBI is a very weird beast, with unanticipated
action-at-a-distance issues that crop up here and there. It's crazy
stuff like this that led me to abandon it -- at first for
DBI->connect_cached (though I had to do some extra work to make sure it
was safe), and more recently for DBIx::Connector, which does that extra
work for me.

Can you see what PIDs MySQL is accepting connections from? Are they the
same as currently-running Apache processes? Or are (some of them) from
dead Apache child processes?

Best,

David