You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Lev Lvovsky <li...@sonous.com> on 2006/11/29 06:54:13 UTC
retrieving cached connections
It looks like from reading the docs, that the startup.pl file can
handle specifying more than one user for the purpose of making
multiple connections with different database accounts.
I'm having a problem in retrieving these cached connections when
running the code after server startup. Am I correct in assuming that
specifying identical DBI connection parameters in the mod_perl
handler as those in the startup.pl connections will return the $dbh
of the corresponding cached connection?
In using the 'mysql' client to show a list of connections, I see that
in addition to the several cached connections I create upon startup,
running a mod_perl handler creates another db connection (not using
the cached one).
Any pointers appreciated.
thanks,
-lev
Re: retrieving cached connections
Posted by Jonathan <mo...@2xlp.com>.
On Nov 29, 2006, at 2:46 PM, Philip M. Gollucci wrote:
> Michael Peters wrote:
>> + # we can only do our magic if DBI isn't already loaded
>> + warn "Apache::DBI must be loaded after DBI to work correctly";
> I like it -- any objects list ?
i REALLY like that idea.
it solves the problem AND teaches people how to do things the right way.
+1
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
Re: retrieving cached connections
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Keep it on list -- others have the same question 'trust me'
Lev Lvovsky wrote:
> Philip, not sure if this is possible, but what happens if Apache::DBI is
> loaded in the correct order the first time, but then afterwards loaded
> again after DBI has been loaded - does the Perl loader make sure this
> doesn't happen to begin with?
Basically when you do a 'require'
$ perldoc -f require
Otherwise, "require" demands that a library file be included if
it hasn't already been included. The file is included via the
do-FILE mechanism, which is essentially just a variety of
"eval". Has semantics similar to the following subroutine:
[routine is in the docs, but snipped here]
It checks %INC first.
$ perldoc -f use
Imports some semantics into the current package from the named
module, generally by aliasing certain subroutine or variable
names into your package. It is exactly equivalent to
BEGIN { require Module; import Module LIST; }
except that Module must be a bareword.
so if you have loaded it already correctly, you are fine.
The reason this order matters is a DBI internals -- its actually
Apache::DBI aware not vice-versa. DBI forwards to Apache-DBI not
Apache-DBI intercepts DBI.
# check if user wants a persistent database connection ( Apache +
# mod_perl )
if ($INC{'Apache/DBI.pm'} && $ENV{MOD_PERL}) {
$DBI::connect_via = "Apache::DBI::connect";
DBI->trace_msg("DBI connect via $DBI::connect_via in
$INC{'Apache/DBI.pm'}\n");
}
This happens once at load time since its outside a function -- (first
load aka startup.pl)
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
Re: retrieving cached connections
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Michael Peters wrote:
> --- DBI.pm.old 2006-11-29 14:30:56.000000000 -0500
> +++ DBI.pm 2006-11-29 14:32:05.000000000 -0500
> @@ -15,6 +15,10 @@
> $modperl::VERSION < 1.99) {
> require Apache;
> }
> +
> + # we can only do our magic if DBI isn't already loaded
> + warn "Apache::DBI must be loaded after DBI to work correctly";
^^^^^ BEFORE :)
> + if $INC{'DBI.pm'};
> }
> use DBI ();
> use Carp ();
I like it -- any objects list ?
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
Re: Apache::VMonitor doesn't install (can't find Apache::Scoreboard): suggested patch
Posted by Malcolm J Harwood <mj...@liminalflux.net>.
On Tuesday 05 December 2006 20:33, David Scott wrote:
> I *finally* managed to get this to work. The problem is in
> Apache::Scoreboard, in Scoreboard.xs: apparently
> ap_exists_scoreboard_image() can return the value 0 even when everything
> is OK,
Can I ask how you found that out? I've been trying to find a cause for the
issue mentioned below, without much luck (but also without much time).
> causing the existence test to fail and Apache::Scoreboard not to
> load.
Which version of Apache are you using? There's a known issue with
Apache::VMonitor not loading if you try to load it too soon (eg. from a
PostConfigRequire) with more recent versions of Apache. (It's mentioned in
the Apache::VMonitor docs). It could be the same issue.
> The following patch to Scoreboard.xs seems to do the trick:
>
> 342c342
> < if (ap_exists_scoreboard_image()) {
> ---
>
> > if ( image != NULL ) {
>
> I hope this makes life easier for other people. Apache::VMonitor really
> is a nice tool.
Thanks. I'll test the change locally and upload a new version as soon as I get
chance.
Re: Apache::VMonitor doesn't install (can't find
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
David Scott wrote:
> Hey guys,
>
> I've installed Apache 2.2.3 and mod_perl 2.0.3 + libapreq2, apparently
> all successfully (my application runs pretty well). Now I want to
> install Apache::VMonitor and can't.
>
> I've running on Debian sarge and have Apache 1.3.33 installed as well in
> /usr/sbin/apache.
Where are your two apxs binaries (full path) ?
$ echo $PATH
$ which apxs
> The first issue is when I install Apache::Scoreboard 2.0.8. make works
> OK, but make test fails with:
MOD_PERL=2 $perl Makefile.PL -apxs /path/to/apxs_for_2.x
(Or you could just put the path to the apxs you want FIRST in your path)
> mp gen = 2
> INC = /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4
> /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8
> /usr/local/lib/site_perl .
> Going to build against mod_perl/2.000003 Perl/5.008004
> perl -e 'print "INC = @INC\n"; use Apache::Scoreboard; print "version =
> $Apache::Scoreboard::VERSION\n";'
>
> I get:
>
> INC = /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4
> /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8
> /usr/local/lib/site_perl .
> version = 2.08
Yes, but is that in 5.8.4 or 5.8.8 -- being an Apache-Scoreboard
is XS based module so thats going to make a difference.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
Apache::VMonitor doesn't install (can't find
Posted by David Scott <ds...@earthlink.net>.
Hey guys,
I've installed Apache 2.2.3 and mod_perl 2.0.3 + libapreq2, apparently
all successfully (my application runs pretty well). Now I want to
install Apache::VMonitor and can't.
I've running on Debian sarge and have Apache 1.3.33 installed as well in
/usr/sbin/apache.
The first issue is when I install Apache::Scoreboard 2.0.8. make works
OK, but make test fails with:
make[1]: Entering directory `/usr/local/Apache-Scoreboard-2.08/Dummy'
make[1]: Leaving directory `/usr/local/Apache-Scoreboard-2.08/Dummy'
/usr/bin/perl -Iblib/arch -Iblib/lib \
t/TEST -clean
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl
/usr/local/Apache-Scoreboard-2.08/t/TEST -clean
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT=
APACHE_TEST_USER= APACHE_TEST_APXS= \
/usr/bin/perl -Iblib/arch -Iblib/lib \
t/TEST -bugreport -verbose=0
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl
/usr/local/Apache-Scoreboard-2.08/t/TEST -bugreport -verbose=0
/usr/sbin/apache -d /usr/local/Apache-Scoreboard-2.08/t -f
/usr/local/Apache-Scoreboard-2.08/t/conf/httpd.conf -D APACHE1 -D
PERL_USEITHREADS
===>>> using Apache/1.3.33
waiting 60 seconds for server to start: .Syntax error on line 14 of
/usr/local/Apache-Scoreboard-2.08/t/conf/extra.conf:
Invalid command 'PerlSwitches', perhaps mis-spelled or defined by a
module not included in the server configuration
[ error]
server has died with status 255 (t/logs/error_log wasn't created, start
the server in the debug mode)
make: *** [run_tests] Error 143
Apparently, apxs is locating my Apache 1.3 binary and ignoring Apache
2.2. This only causes the test to fail, because I can do make install
with no issues.
Then I go to compile Apache::VMonitor with
MOD_PERL=2 perl Makefile.PL
It can't find my compiled Apache::Scoreboard. I've dumped some
Makefile.PL variables for reference:
mp gen = 2
INC = /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4
/usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8
/usr/local/lib/site_perl .
Going to build against mod_perl/2.000003 Perl/5.008004
[ info] generating script t/TEST
$VAR1 = 'NAME';
$VAR2 = 'Apache::VMonitor';
$VAR3 = 'clean';
$VAR4 = {
'FILES' => 't/TEST'
};
$VAR5 = 'VERSION_FROM';
$VAR6 = 'lib/Apache/VMonitor.pm';
$VAR7 = 'PREREQ_PM';
$VAR8 = {
'Apache::Scoreboard' => '2.08',
'Apache::Test' => '1.15',
'mod_perl2' => '2.0',
'Time::HiRes' => '1.19',
'Template' => '2.0',
'GTop' => '0.12'
};
Warning: prerequisite Apache::Scoreboard 2.08 not found.
Writing Makefile for Apache::VMonitor
But Apache::Scoreboard 2.08 is in my @INC path. When I do:
perl -e 'print "INC = @INC\n"; use Apache::Scoreboard; print "version =
$Apache::Scoreboard::VERSION\n";'
I get:
INC = /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4
/usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8
/usr/local/lib/site_perl .
version = 2.08
Some internal magic is obviously taking place here and I don't know what
it is.
If I continue on with the installation of Apache::VMonitor, make doesn't
complain but make test gives:
/usr/bin/perl -Iblib/arch -Iblib/lib \
t/TEST -clean
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl
/usr/local/Apache-VMonitor-2.06/t/TEST -clean
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT=
APACHE_TEST_USER= APACHE_TEST_APXS= \
/usr/bin/perl -Iblib/arch -Iblib/lib \
t/TEST -bugreport -verbose=0
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl
/usr/local/Apache-VMonitor-2.06/t/TEST -bugreport -verbose=0
/usr/sbin/apache -d /usr/local/Apache-VMonitor-2.06/t -f
/usr/local/Apache-VMonitor-2.06/t/conf/httpd.conf -D APACHE1 -D
PERL_USEITHREADS
--->>> using Apache/1.3.33
waiting 60 seconds for server to start: ===>>> ./usr/sbin/apache:
relocation error:
/usr/local/lib/perl/5.8.4/auto/Apache/Scoreboard/Scoreboard.so:
undefined symbol: ap_mpm_query
[ error]
server has died with status 255 (t/logs/error_log wasn't created, start
the server in the debug mode)
make: *** [run_tests] Error 143
Again the Apache 1.3 problem - and lo and behold there's a binary
compatibility issue.
I'm kind of at wit's end about what to do here - clearly apxs is not
being my friend, but what can I do about it?
Thanks.
David
Re: Apache::VMonitor doesn't install (can't find Apache::Scoreboard)
Posted by David Scott <ds...@earthlink.net>.
This helps, but the real problem appears to be that Apache::Scoreboard
isn't built properly in the first place. I had ExtUtils::MakeMaker
print out $@ after it tries to load Apache::Scoreboard 2.08 for VMonitor
and got the following:
error: Can't load
'/usr/local/lib/perl/5.8.4/auto/Apache/Scoreboard/Scoreboard.so' for
module Apache::Scoreboard:
/usr/local/lib/perl/5.8.4/auto/Apache/Scoreboard/Scoreboard.so:
undefined symbol: ap_scoreboard_image at /usr/lib/perl/5.8/XSLoader.pm
line 68.
at /usr/local/lib/perl/5.8.4/Apache/Scoreboard.pm line 21
...which appears to be the smoking gun. Is there something I need to do
when building httpd in the first place? Do I need to tweak
LD_LIBRARY_PATH or something?
Thanks.
d
Philip M. Gollucci wrote:
> David Scott wrote:
>> make test APACHE_TEST_HTTPD=/usr/local/apache2/bin/httpd
>> APACHE_TEST_APXS=/usr/local/apache2/bin/apxs
>>
>> but this has no effect in the other install phases, (and doesn't help
>> with Apache::VMonitor at all).
> You can edit "permenantely" which httpd server A-T is setup to use.
>
> # determine which configuration file Apache/TestConfigData.pm to use
> # (as there could be several). The order searched is:
> # 1) $ENV{HOME}/.apache-test/
> # 2) in @INC
>
Re: Apache::VMonitor doesn't install (can't find Apache::Scoreboard)
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
David Scott wrote:
> make test APACHE_TEST_HTTPD=/usr/local/apache2/bin/httpd
> APACHE_TEST_APXS=/usr/local/apache2/bin/apxs
>
> but this has no effect in the other install phases, (and doesn't help
> with Apache::VMonitor at all).
You can edit "permenantely" which httpd server A-T is setup to use.
# determine which configuration file Apache/TestConfigData.pm to use
# (as there could be several). The order searched is:
# 1) $ENV{HOME}/.apache-test/
# 2) in @INC
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
Apache::VMonitor doesn't install (can't find Apache::Scoreboard)
Posted by David Scott <ds...@earthlink.net>.
Phillip wrote:
>> Hey guys,
>>
>> I've installed Apache 2.2.3 and mod_perl 2.0.3 + libapreq2, >apparently
>> all successfully (my application runs pretty well). Now I want to
>> install Apache::VMonitor and can't.
>>
>> I've running on Debian sarge and have Apache 1.3.33 installed as
> well >in
>> /usr/sbin/apache.
>Where are your two apxs binaries (full path) ?
>$ echo $PATH
>$ which apxs
OK in my first tests apxs isn't in my path (or root's path) anywhere
('which apxs' is empty). The apache2 apxs is in
/usr/local/apache2/bin/apxs. (There is an apxs in
/usr/local/apache/bin/apxs, but this isn't in the PATH either.) See
below.
>> The first issue is when I install Apache::Scoreboard 2.0.8. make
>works
>> OK, but make test fails with:
>MOD_PERL=2 $perl Makefile.PL -apxs /path/to/apxs_for_2.x
This has no effect, except that Makefile.PL complains that apxs isn't a
valid parameter (probably OK).
>(Or you could just put the path to the apxs you want FIRST in your >path)
MOD_PERL=2 PATH="/usr/local/apache2/bin:$PATH" perl Makefile.PL has no
effect.
In fact I went and added /usr/local/apache2/bin to my path in the bash
shell, so that now
which apxs
gives
/usr/local/apache2/bin/apxs
...and this has no effect.
I *can* get make test to work for Apache::Scoreboard by using
make test APACHE_TEST_HTTPD=/usr/local/apache2/bin/httpd
APACHE_TEST_APXS=/usr/local/apache2/bin/apxs
but this has no effect in the other install phases, (and doesn't help
with Apache::VMonitor at all).
David
Re: Instability at startup for Apache2/mod_perl2 using worker MPM
Posted by Robert Landrum <rl...@aol.net>.
Perrin Harkins wrote:
> David Scott wrote:
>> I've built Apache 2.2.3 and mod_perl 2.0.3 with libapreq 2.08 and the
>> worker MPM. There appears to be some kind of race condition at
>> startup that prevents the server from coming up. This only happens
>> once in a while, and can be fixed by some minor configuration or code
>> change (ie, adding a 'print STDERR "foobar\n"' to one of my Perl
>> modules can cause the problem to occur; moving the print statement by
>> one line can fix it).
>
> This sounds like a possible issue with your code and threaded perl. It
> doesn't ring a bell as a general mod_perl issue.
>
Interesting problem. I remember reading about an issue with threading
(not specific to apache or mod_perl) that occured when file descriptors
were being modified while there were contents in the buffer.
Just for giggles, try
{
local $|=1;
use MyModules;
...
}
Rob
Re: Instability at startup for Apache2/mod_perl2 using worker MPM
Posted by Perrin Harkins <pe...@elem.com>.
David Scott wrote:
> I've built Apache 2.2.3 and mod_perl 2.0.3 with libapreq 2.08 and the
> worker MPM. There appears to be some kind of race condition at startup
> that prevents the server from coming up. This only happens once in a
> while, and can be fixed by some minor configuration or code change (ie,
> adding a 'print STDERR "foobar\n"' to one of my Perl modules can cause
> the problem to occur; moving the print statement by one line can fix it).
This sounds like a possible issue with your code and threaded perl. It
doesn't ring a bell as a general mod_perl issue.
> I've been porting a fairly complex pure-Perl legacy application from
> mod_perl 1 to mod_perl 2. The reason we're trying this is because
> memory requirements in MP1 are horrendous and child process death is
> extremely expensive.
Do you realize that it will take MORE memory when run with threads? If
you want to keep memory down, use the prefork MPM. See the list
archives for discussion about memory and Perl threads. Also, threads
slow down startup since a lot of work has to be done when spawning them
to copy all the data structures for each one.
> In addition, it's not unusual for the mod_perl 1 server to take a long
> time to start up or shut down.
Slow startup on mod_perl 1 usually means you are compiling a lot of code
or doing some other time-consuming thing in your startup code, like
maybe talking to a database.
> Does anyone have suggestions on how I can
> track down the problem?
I'd start by switching to prefork and seeing if it's still there. If it
is, the most reliable method is to take things out until the problem
goes away. It's not instant gratification, but it works.
- Perrin
Instability at startup for Apache2/mod_perl2 using worker MPM
Posted by David Scott <ds...@earthlink.net>.
OK this is my third message today, hopefully it will be the last.
I've built Apache 2.2.3 and mod_perl 2.0.3 with libapreq 2.08 and the
worker MPM. There appears to be some kind of race condition at startup
that prevents the server from coming up. This only happens once in a
while, and can be fixed by some minor configuration or code change (ie,
adding a 'print STDERR "foobar\n"' to one of my Perl modules can cause
the problem to occur; moving the print statement by one line can fix it).
There are two manifestations of this problem: either
(1) The first httpd process goes to 99% CPU usage and stays there
indefinitely, never doing a restart; or
(2) The restart occurs and the new parent process forks *one* child and
then goes to 99% CPU usage indefinitely, never completing the startup
sequence.
I've been porting a fairly complex pure-Perl legacy application from
mod_perl 1 to mod_perl 2. The reason we're trying this is because
memory requirements in MP1 are horrendous and child process death is
extremely expensive. The application appears to work fine once the
Apache2 server starts.
In addition, it's not unusual for the mod_perl 1 server to take a long
time to start up or shut down.
I suspect that there is some nasty interaction between my Perl modules
(of which there are many). Does anyone have suggestions on how I can
track down the problem? Apache2::Status is useless until the server
starts, obviously.
Here is my system information:
Apache/2.2.3 (Unix) mod_apreq2-20051231/2.6.0 mod_perl/2.0.3 Perl/v5.8.4
configured -- resuming normal operations
[Thu Nov 30 14:15:39 2006] [info] Server built: Nov 29 2006 17:32:31
Also, here is perl -V:
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=linux, osvers=2.6.15.4, archname=i386-linux-thread-multi
uname='linux ninsei 2.6.15.4 #1 smp preempt mon feb 20 09:48:53 pst
2006 i686 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr
-Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5
-Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local
-Dsitelib=/usr/local/share/perl/5.8.4
-Dsitearch=/usr/local/lib/perl/5.8.4 -Dman1dir=/usr/share/man/man1
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm
-Duseshrplib -Dlibperl=libperl.so.5.8.4 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3.5 (Debian 1:3.3.5-13)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true,
libperl=libperl.so.5.8.4
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Mar 23 2006 21:49:08
@INC:
/etc/perl
/usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
.
Thanks again.
David
Re: Apache2::Status "Memory Usage" fails on Debian
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
David Scott wrote:
> The following patch makes life a lot easier:
>
> in B::TerseSize:
>
> 631c631
> < my $script = $q->script_name;
> ---
> > my $script = ( defined $q && $q ) ? $q->script_name : $r->uri;
>
> The problem is, the Apache 2 API doesn't use CGI query objects at all so
> you can't use the script name.
my $script = MP2 ? $r->uri : $q->script_name;
is better I think.
This will be in the very soon to be released B-Size 0.09
and I'll update mp2 svn to depend on a minium version of 0.09 for
B::TerseSize which is in the B-Size CPAN module.
Thanks John, Scott.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB B89E 1324 9B4F EC88 A0BF
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
Re: Apache2::Status "Memory Usage" fails on Debian
Posted by David Scott <ds...@earthlink.net>.
The following patch makes life a lot easier:
in B::TerseSize:
631c631
< my $script = $q->script_name;
---
> my $script = ( defined $q && $q ) ? $q->script_name : $r->uri;
The problem is, the Apache 2 API doesn't use CGI query objects at all so
you can't use the script name.
d
Jonathan wrote:
>
> On Nov 30, 2006, at 5:58 PM, David Scott wrote:
>
>> This is not a good Apache day. I already sent out a message
>> regarding an Apache::Scoreboard problem, and now Apache2::Status
>> doesn't work either.
>
> it's a bug, but i think its platform specific/ odd
>
> i ran into the same thing a while back
>
> check out this:
>
> http://comments.gmane.org/gmane.comp.apache.mod-perl/24906
>
> i have 2 posts at the bottom, which i'll just paste here:
>
> =====
> Jonathan | 13 Aug 00:46
>
> I'm finding some issues with the 2 modules
>
> i think some of it happens when you have a module that has no
> subroutines ( ie , a namespace placeholder or something )
>
> check out ~ line 551 in Apache2::Status
>
> adding a few over-the-top checks seems to help, and gets memory use
> working on more items
>
> } (sort { $subs->{$b}->{size} <=> $subs->{$a}->{size} } keys %
> $subs);
>
> + return if ! scalar <at> keys;
> + return if ! defined $subs->{$keys[0]};
> + return if ! defined $subs->{$keys[0]}->{count};
> + return if ! defined $subs->{$keys[0]}->{size};
>
> my $clen = length $subs->{$keys[0]}->{count};
> my $slen = length $subs->{$keys[0]}->{size};
>
> i'll have more fixes as time progresses
>
> ======
>
> Jonathan | 13 Aug 00:56
>
> ok, also found
>
> I also figured this out:
>
> in B::TerseSize, line 634
>
> - my $script = $q->script_name;
>
> + my $script ;
> + if ( defined $q && $q )
> + {
> + $script = $q->script_name;
> + }
>
> Killing that makes a lot more things work too.
>
> The only caveat of that, is that 'memory usage' doesn't appear on /
> perl-status/ until you visit a symdump page that contains memory-
> usage. i don't know why. but that should only happen on situations
> already afflicted by the other bug. so its a stupid new bug instead
> of a bad old one.
>
> ==========
>
>
>
> // Jonathan Vanasco
>
> | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - -
> | FindMeOn.com - The cure for Multiple Web Personality Disorder
> | Web Identity Management and 3D Social Networking
> | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - -
> | RoadSound.com - Tools For Bands, Stuff For Fans
> | Collaborative Online Management And Syndication Tools
> | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - -
>
>
>
Re: Apache2::Status "Memory Usage" fails on Debian
Posted by Jonathan <mo...@2xlp.com>.
On Nov 30, 2006, at 5:58 PM, David Scott wrote:
> This is not a good Apache day. I already sent out a message
> regarding an Apache::Scoreboard problem, and now Apache2::Status
> doesn't work either.
it's a bug, but i think its platform specific/ odd
i ran into the same thing a while back
check out this:
http://comments.gmane.org/gmane.comp.apache.mod-perl/24906
i have 2 posts at the bottom, which i'll just paste here:
=====
Jonathan | 13 Aug 00:46
I'm finding some issues with the 2 modules
i think some of it happens when you have a module that has no
subroutines ( ie , a namespace placeholder or something )
check out ~ line 551 in Apache2::Status
adding a few over-the-top checks seems to help, and gets memory use
working on more items
} (sort { $subs->{$b}->{size} <=> $subs->{$a}->{size} } keys %
$subs);
+ return if ! scalar <at> keys;
+ return if ! defined $subs->{$keys[0]};
+ return if ! defined $subs->{$keys[0]}->{count};
+ return if ! defined $subs->{$keys[0]}->{size};
my $clen = length $subs->{$keys[0]}->{count};
my $slen = length $subs->{$keys[0]}->{size};
i'll have more fixes as time progresses
======
Jonathan | 13 Aug 00:56
ok, also found
I also figured this out:
in B::TerseSize, line 634
- my $script = $q->script_name;
+ my $script ;
+ if ( defined $q && $q )
+ {
+ $script = $q->script_name;
+ }
Killing that makes a lot more things work too.
The only caveat of that, is that 'memory usage' doesn't appear on /
perl-status/ until you visit a symdump page that contains memory-
usage. i don't know why. but that should only happen on situations
already afflicted by the other bug. so its a stupid new bug instead
of a bad old one.
==========
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
Re: Instability at startup for Apache2/mod_perl2 using worker MPM
Posted by Perrin Harkins <pe...@elem.com>.
David Scott wrote:
> We will probably be moving to
> DBIx::Class (which is supposed to function well in multithreaded Apache)
> rather than vanilla DBI. If anyone has experience with DBIx::Class on
> mod_perl2 using the worker MPM, we would be grateful to hear from you.
DBIx::Class is just a library that uses DBI, so the threading issues are
not really changed by it. The question for you will be how well your
chosen database library (DBD::whatever) supports running in perl
threads. It may be no problem, or there may be global data structures
on the XS side that make it impossible. You'd be best off asking on the
dbi-users list or a specific list for your DBD module.
- Perrin
Re: Instability at startup for Apache2/mod_perl2 using worker MPM
Posted by David Scott <ds...@earthlink.net>.
Just a note to thank all those who helped me with my three (3) Apache2
problems last week. Here is how it all worked out:
- There was an apparent bug in Scoreboard.xs in Apache::Scoreboard 2.08
that prevented its being loaded into Apache::VMonitor. Malcolm is
looking into this (thanks).
- There was an another glitch in B::TerseSize. Thanks to Philip for
looking into this.
- We decided to go with the prefork MPM for now, at least until we can
get some of our more gnarly platform issues sorted out. In fact, memory
management in Apache2 appears to be vastly improved over Apache1, even
with the prefork MPM, so our performance is already better just with
that change.
We are still interested in the worker MPM, and would appreciate any "war
stories" about thread-safety, etc. We will probably be moving to
DBIx::Class (which is supposed to function well in multithreaded Apache)
rather than vanilla DBI. If anyone has experience with DBIx::Class on
mod_perl2 using the worker MPM, we would be grateful to hear from you.
Again, thanks to everyone.
d
David Scott wrote:
> This is not a good Apache day. I already sent out a message regarding
> an Apache::Scoreboard problem, and now Apache2::Status doesn't work
> either.
Apache2::Status "Memory Usage" fails on Debian
Posted by David Scott <ds...@earthlink.net>.
This is not a good Apache day. I already sent out a message regarding
an Apache::Scoreboard problem, and now Apache2::Status doesn't work either.
Here is an excerpt from httpd.conf:
ExtendedStatus On
PerlLoadModule Apache2::Status
PerlModule CGI
PerlModule B::TerseSize
Listen 7777
<VirtualHost *:7777>
<Location /perl-status>
SetHandler modperl
PerlOptions +GlobalRequest
PerlResponseHandler Apache2::Status
PerlSetVar StatusOptionsAll On
PerlSetVar StatusTerseSizeMainSummary On
PerlSetVar StatusDeparseOptions "-p -sC"
</Location>
</VirtualHost>
Whan I access perl-status, I get the following menu items:
Environment
Loaded Modules
Inheritance Tree
ISA Tree
HTML::Mason status
Perl Configuration
Compiled Registry Scripts
PerlRequire'd Files
Signal Handlers
Memory Usage
Symbol Table Dump
Everything works fine except Memory Usage, which complains to the error_log:
[Thu Nov 30 14:15:53 2006] [error] [client 127.0.0.1] Can't call method
"script_name" on an undefined value at
/usr/local/lib/perl/5.8.4/B/TerseSize.pm line 631.\n, referer:
http://localhost:7777/perl-status
At the offending line in TerseSize.pm, the $q variable is undefined.
From the docs, I take it this is a CGI object. Why is it undefined?
What is it supposed to be? Where is the CGI script? Am I supposed to
do something?
I'm sure that this has come up before and that there is a simple answer
to all this but I'd like to track memory usage in Apache2/mod_perl2 and
have been frustrated at every turn.
I'm using Apache 2.2.3 and mod_perl 2.0.3 with libapreq 2.08:
Apache/2.2.3 (Unix) mod_apreq2-20051231/2.6.0 mod_perl/2.0.3 Perl/v5.8.4
configured -- resuming normal operations
[Thu Nov 30 14:15:39 2006] [info] Server built: Nov 29 2006 17:32:31
Also, here is perl -V:
Summary of my perl5 (revision 5 version 8 subversion 4) configuration:
Platform:
osname=linux, osvers=2.6.15.4, archname=i386-linux-thread-multi
uname='linux ninsei 2.6.15.4 #1 smp preempt mon feb 20 09:48:53 pst
2006 i686 gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr
-Dprivlib=/usr/share/perl/5.8 -Darchlib=/usr/lib/perl/5.8
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5
-Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local
-Dsitelib=/usr/local/share/perl/5.8.4
-Dsitearch=/usr/local/lib/perl/5.8.4 -Dman1dir=/usr/share/man/man1
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm
-Duseshrplib -Dlibperl=libperl.so.5.8.4 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS
-DDEBIAN -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O2',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3.5 (Debian 1:3.3.5-13)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true,
libperl=libperl.so.5.8.4
gnulibc_version='2.3.2'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Mar 23 2006 21:49:08
@INC:
/etc/perl
/usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
.
Thanks. I'd really like to get past this.
David
Apache::VMonitor doesn't install (can't find Apache::Scoreboard):
suggested patch
Posted by David Scott <ds...@earthlink.net>.
I *finally* managed to get this to work. The problem is in
Apache::Scoreboard, in Scoreboard.xs: apparently
ap_exists_scoreboard_image() can return the value 0 even when everything
is OK, causing the existence test to fail and Apache::Scoreboard not to
load.
The following patch to Scoreboard.xs seems to do the trick:
342c342
< if (ap_exists_scoreboard_image()) {
---
> if ( image != NULL ) {
I hope this makes life easier for other people. Apache::VMonitor really
is a nice tool.
d
Phillip wrote:
>> Hey guys,
>>
>> I've installed Apache 2.2.3 and mod_perl 2.0.3 + libapreq2, >apparently
>> all successfully (my application runs pretty well). Now I want to
>> install Apache::VMonitor and can't.
>>
>> I've running on Debian sarge and have Apache 1.3.33 installed as
> well >in
>> /usr/sbin/apache.
>Where are your two apxs binaries (full path) ?
>$ echo $PATH
>$ which apxs
Re: retrieving cached connections
Posted by Larry Leszczynski <la...@emailplus.org>.
On Thu, 30 Nov 2006, Michael Peters wrote:
>>> Maybe you could have Apache::DBI issue a warning if it's being loaded
>>> and DBI has already been loaded. Something as simple as the attached
>>> patch should work.
>>>
>>> + # we can only do our magic if DBI isn't already loaded
>>> + warn "Apache::DBI must be loaded after DBI to work correctly";
>>> + if $INC{'DBI.pm'};
>>
>> Great idea! But don't you mean:
>> Apache::DBI must be loaded before DBI to work correctly
>
> You're right. That was a pretty dumb typo :)
Michael, I hope you didn't think that was a jab at you! It would be
ironic if that typo slipped through, and suddenly a simple patch meant to
reduce confusion ended up creating even more. :-)
Larry
Re: retrieving cached connections
Posted by Michael Peters <mp...@plusthree.com>.
Larry Leszczynski wrote:
>
> On Wed, 29 Nov 2006, Michael Peters wrote:
>
>> Maybe you could have Apache::DBI issue a warning if it's being loaded
>> and DBI has already been loaded. Something as simple as the attached
>> patch should work.
>>
>> + # we can only do our magic if DBI isn't already loaded
>> + warn "Apache::DBI must be loaded after DBI to work correctly";
>> + if $INC{'DBI.pm'};
>
> Great idea! But don't you mean:
> Apache::DBI must be loaded before DBI to work correctly
You're right. That was a pretty dumb typo :)
--
Michael Peters
Developer
Plus Three, LP
Re: retrieving cached connections
Posted by Larry Leszczynski <la...@emailplus.org>.
On Wed, 29 Nov 2006, Michael Peters wrote:
> Maybe you could have Apache::DBI issue a warning if it's being loaded
> and DBI has already been loaded. Something as simple as the attached
> patch should work.
>
> + # we can only do our magic if DBI isn't already loaded
> + warn "Apache::DBI must be loaded after DBI to work correctly";
> + if $INC{'DBI.pm'};
Great idea! But don't you mean:
Apache::DBI must be loaded before DBI to work correctly
^^^^^^
?
Re: retrieving cached connections
Posted by Michael Peters <mp...@plusthree.com>.
Philip M. Gollucci wrote:
> If you can suggest a documentation patch you feel clarify things, I'll
> read it over and commit for version 1.06 (sorry about that 1.05 is current)
Maybe you could have Apache::DBI issue a warning if it's being loaded and DBI
has already been loaded. Something as simple as the attached patch should work.
--
Michael Peters
Developer
Plus Three, LP
Re: retrieving cached connections
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Lev Lvovsky wrote:
>
> On Nov 28, 2006, at 11:03 PM, Philip M. Gollucci wrote:
>
>> is this mod_perl 1 or 2 ?
>> Setting $Apache::DBI::Debug = 2; and watching you're error log file
>> should tell you what its doing.
>>
>> package X;
>> # database
>> our $host = 'mysql.x.y';
>> our $dsn = "dbi:mysql:db;host=$host";
>> our $user = 'u';
>> our $pass = 'p';
>> our %db_attrs = (
>
> Thanks Philip - it turns out that our problem was the order that we were
> doing things in. First the 'use' statements were not in the correct
> order, and we were only connecting to the DB once in the very beginning
> of the mod_perl handler (before the handler() sub itself). Looking
> through the Apache::DBI code, it's now a bit more clear what the usage
> is - since the ping functionality is built-in to connect(), whenever the
> handler is hit now, we call the connect() then, and let Apache::DBI take
> care of everything else - works like a charm.
>
> Now we might add more error handling around the begin_work section in
> case the DB connection drops immediately after the connect() is called
> but before the begin_work is called.
If you can suggest a documentation patch you feel clarify things, I'll
read it over and commit for version 1.06 (sorry about that 1.05 is current)
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
Re: retrieving cached connections
Posted by Lev Lvovsky <li...@sonous.com>.
On Nov 28, 2006, at 11:03 PM, Philip M. Gollucci wrote:
> is this mod_perl 1 or 2 ?
> Setting $Apache::DBI::Debug = 2; and watching you're error log file
> should tell you what its doing.
>
> package X;
> # database
> our $host = 'mysql.x.y';
> our $dsn = "dbi:mysql:db;host=$host";
> our $user = 'u';
> our $pass = 'p';
> our %db_attrs = (
Thanks Philip - it turns out that our problem was the order that we
were doing things in. First the 'use' statements were not in the
correct order, and we were only connecting to the DB once in the very
beginning of the mod_perl handler (before the handler() sub itself).
Looking through the Apache::DBI code, it's now a bit more clear what
the usage is - since the ping functionality is built-in to connect(),
whenever the handler is hit now, we call the connect() then, and let
Apache::DBI take care of everything else - works like a charm.
Now we might add more error handling around the begin_work section in
case the DB connection drops immediately after the connect() is
called but before the begin_work is called.
thanks for all the help!
-lev
Re: retrieving cached connections
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Lev Lvovsky wrote:
> It looks like from reading the docs, that the startup.pl file can handle
> specifying more than one user for the purpose of making multiple
> connections with different database accounts.
>
> I'm having a problem in retrieving these cached connections when running
> the code after server startup. Am I correct in assuming that specifying
> identical DBI connection parameters in the mod_perl handler as those in
> the startup.pl connections will return the $dbh of the corresponding
> cached connection?
> In using the 'mysql' client to show a list of connections, I see that in
> addition to the several cached connections I create upon startup,
> running a mod_perl handler creates another db connection (not using the
> cached one).
>
> Any pointers appreciated.
is this mod_perl 1 or 2 ?
Setting $Apache::DBI::Debug = 2; and watching you're error log file
should tell you what its doing.
package X;
# database
our $host = 'mysql.x.y';
our $dsn = "dbi:mysql:db;host=$host";
our $user = 'u';
our $pass = 'p';
our %db_attrs = (
RaiseError => 1,
PrintError => 0,
Taint => 0,
AutoCommit => 1,
LongReadLen => 50000,
LongTruncOk => 1,
ShowErrorStatement => 1,
ChopBlanks => 1,
FetchHashKeyName => "NAME_lc",
);
startup.pl:
use X ();
use Apache::DBI (); ## order matters
use DBI (); ## this must be the first use of DBI
Apache::DBI->connect_on_init($X::dsn, $X::user, $X::pass,\%X::attrs);
## having made the above comments, you can do this in httpd.conf also
## using PerlModule lines.
package Y;
use X ();
use DBI ();
use Apache2::Log ();
use Apache2::RequestRec ();
sub get_dbh {
my $r = shift;
my $dbh = eval {
DBI->connect($X::dsn, $X::user, $X::pass, \%X:db_attrs)
};
$r->log_error($@) if $@;
return $dbh;
}
package Z;
use Y ();
sub handler {
my $r = shift;
my $dbh = Y::get_dbh($r);
....
}
What you should end up with is 1 connection per child (assuming prefork)
When you connect, you should get one of those back. If you don't,
you're config is screwed, or your parameters are different.
see also the eg/ directory of the Apache-DBI-1.06.tar.gz
HTH
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.