Re: [mp2] a little OT, problem finding libapr
I'd suggest to completely nuke /usr/local/apache2, install Apache from scratch and chances are that everything will work fine. You have too many old libs there. I'll give that a go tonight or tomorrow when I get a few spare hours, thanks! -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Apache::DBI patch to disconnect idle connections
J Robert Ray wrote: What I want from connection pooling is to cache database connections for a relatively short period of time, such as while a user is actively clicking around a web application. Once that user leaves the application, ideally the database connections would expire. You might have better success by simply changing the session inactivity timeout on your database server. This would require no changes to Apache::DBI, and avoids the drawbacks you mentioned at the end. If someone comes in and tries to use a timed out connection, Apache::DBI will just reconnect. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Apache::DBI patch to disconnect idle connections
This patch changes the behavior of Apache::DBI so that it no longer
holds onto connections for as long as the httpd child lives.
Brief background: I am working to keep the total connection count to our
database as low as possible. Apache::DBI tends to accumulate database
connections over time, including connections from rarely-accessed CGI
programs. I wanted a way to limit the connection count beyond the child
spawning and lifespan configuration options Apache gives me.
What I want from connection pooling is to cache database connections for
a relatively short period of time, such as while a user is actively
clicking around a web application. Once that user leaves the
application, ideally the database connections would expire.
The logic of this patch is to keep a timestamp for every connection in
the pool, the timestamp is updated whenever a connect() call comes in
for that connection.
On each connect() call, the timestamps of all the open connections are
examined. If any connection is found to have a timestamp older than 1
hour (default, configured with $Apache::DBI::CONN_TTL), that connection
is deleted.
In addition to this, I added some statistics tracking, and updated the
Apache::Status report to show totals for all connections: the number of
times that connection has been requested, a count of how many times the
same connection has been reused, how many times the connection had
failed ping or otherwise needed to be reconnected, and how many times
that connection has been deleted for being idle.
A big downside to this idea is that the server has to be actively asking
for new connections to the database for the code to run and clean out
old connections, and that every apache child process has its own
independent pool of new and old connections. I would like to see some
dependable way to get all the apache children to clean up old
connections on a regular basis.
I am very interested in hearing ideas on how else to address this
problem. Any feedback on this patch is appreciated.
Thanks,
- Robert
--- /tmp/DBI.pm Thu Aug 26 14:59:20 2004
+++ DBI.pm Thu Aug 26 18:53:36 2004
@@ -1,7 +1,7 @@
package Apache::DBI;
use strict;
-# $Id: DBI.pm,v 1.12 2004/02/18 00:18:50 ask Exp $
+# $Id: DBI.pm 40336 2004-08-27 01:53:36Z jrray $
BEGIN { eval { require Apache } }
use DBI ();
@@ -9,20 +9,31 @@
require_version DBI 1.00;
-$Apache::DBI::VERSION = '0.94';
+$Apache::DBI::VERSION = '0.941';
# 1: report about new connect
# 2: full debug output
$Apache::DBI::DEBUG = 0;
#DBI->trace(2);
+# Allow connections to sit idle for only an hour
+$Apache::DBI::CONN_TTL = 3600;
+
my %Connected;# cache for database handles
my @ChildConnect; # connections to be established when a new httpd child is created
my %Rollback; # keeps track of pushed PerlCleanupHandler which can do a rollback
after the request has finished
my %PingTimeOut; # stores the timeout values per data_source, a negative value
de-activates ping, default = 0
my %LastPingTime; # keeps track of last ping per data_source
+my %LastConnTime; # keeps track of when the last time this connection was used
my $Idx; # key of %Connected and %Rollback.
+my %Statistics; # table to keep track of connection usage statistics, keyed
+ # by $Idx
+ # attempts - number of times connect() is called
+ # expired - number of times connection was deleted due to idle
timeout
+ # reused - number of times connection successfully reused
+ # invalid - number of times connection in pool needed to be
recreated
+
# supposed to be called in a startup script.
# stores the data_source of all connections, which are supposed to be created upon
@@ -82,6 +93,9 @@
pop @args;
}
+# This counts as a connect
+$Statistics{$Idx}{attempts}++;
+
# don't cache connections created during server initialization; they
# won't be useful after ChildInit, since multiple processes trying to
# work over the same database connection simultaneously will receive
@@ -112,6 +126,32 @@
print STDERR "$prefix need ping: ", $needping == 1 ? "yes" : "no", "\n" if
$Apache::DBI::DEBUG > 1;
$LastPingTime{$dsn} = $now;
+# clean up old connections
+while (my ($Conn, $Last) = each %LastConnTime) {
+
+# skip the current connection attempt of course
+next if $Conn eq $Idx;
+
+# CONN_TTL < 0 means this behavior is disabled
+last if $Apache::DBI::CONN_TTL < 0;
+
+if ($Last + $Apache::DBI::CONN_TTL < $now) {
+# reap this old connection
+print STDERR "$prefix removing timed-out connection '$Conn'\n" if
$Apache::DBI::DEBUG > 1;
+
+$Statistics{$Conn}{expired}++;
+
+if ($Connected{$Conn} && $Connected{$Conn}->{Active}) {
+$Connected{$Conn}->orig_disconnect();
+}
+
+delete $Conne
Re: Makefile.PL oddities
Dan Wilga wrote: I've noticed a problem for the past version or two of mod_perl, which still seems to be present in _16. I'm calling Makefile.PL like so: perl Makefile.PL MP_COMPAT_1X=1 MP_AP_PREFIX=../httpd-2.0.50 and yet the generated Makefile has: INC = -I/users2/dwilga/mod_perl-1.99_16/src/modules/perl -I/users2/dwilga/mod_perl-1.99_16/xs -I/users2/dwilga/mod_perl-1.99_14/../httpd-2.0.47/include -I/users2/dwilga/mod_perl-1.99_14/../httpd-2.0.47/srclib/apr/include -I/users2/dwilga/mod_perl-1.99_14/../httpd-2.0.47/srclib/apr-util/include -I/users2/dwilga/mod_perl-1.99_14/../httpd-2.0.47/os/unix Note the references to 2.0.47. I do have a 2.0.47 tree there, but that's not what I specified in the commandline. It seems to be keeping settings from a previous version. Looks wrong, but I can't reproduce it. If I specify a different tree with MP_AP_PREFIX it picks it. Please show us the output of env APACHE_TEST_TRACE_LEVEL=debug perl Makefile.PL MP_COMPAT_1X=1 MP_AP_PREFIX=../httpd-2.0.50 OK, so next I figured I'd let it ask me the path, so I left off MP_AP_PREFIX: % perl Makefile.PL MP_COMPAT_1X=1 Reading Makefile.PL args from @ARGV MP_COMPAT_1X = 1 Configure mod_perl with /users2/dwilga/mod_perl-1.99_14/../httpd-2.0.47? [y] n Configuring Apache/2.0.47 mod_perl/1.99_16 Perl/v5.8.0 WARNING: NO_META is not a known parameter. 'NO_META' is not a known MakeMaker parameter name. [ info] generating script t/TEST Writing Makefile for Apache::Test [ info] generating script t/TEST Writing Makefile for ModPerl::Registry Writing Makefile for APR::Base64 Writing Makefile for APR::Brigade ... Notice how I said "n", yet it went ahead and generated the makefiles anyway. Yup, that was incomplete, now should be fixed in the current cvs. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] recirculating (sub)?request output
Dorian Taylor wrote: suppose i wanted to run a subrequest, but instead of outputting the body (or headers, or anything) of that request down the wire, i wanted to snag it for processing in another handler. i tried writing a filter that gathered the content and stuck it in $f->r->prev->notes, but it still flushes the headers of the main request. what would be the most appropriate way to go about doing this kind of thing? The flush that causes headers sent must be there in order to keep things proper. I'm not sure if playing with $r->assbackwards(1) will help. http://perl.apache.org/docs/2.0/api/Apache/RequestRec.html#C_assbackwards_ But if you write an output connection filter than you can certainly do what you plan (you don't even need to run a sub-request). http://perl.apache.org/docs/2.0/user/handlers/filters.html#Connection_Output_Filters -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] a little OT, problem finding libapr
Carl Brewer wrote: 2. Used Components and their Configuration: *** The httpd binary was not found doh! another Apache-Test bug to fix :( *** (apr|apu)-config linking info -L/usr/local/apache2/lib -lapr-0 -lm -lcrypt -lresolv -L/usr/local/apache2/lib -laprutil-0 -lexpat Looks good. It's probably a problem of symlinks then. It should be: ls -l ~/httpd/prefork/lib/libapr-0* -rw-r--r-- 1 stas stas 475250 Aug 20 12:19 /home/stas/httpd/prefork/lib/libapr-0.a -rw-r--r-- 1 stas stas 765 Aug 20 12:19 /home/stas/httpd/prefork/lib/libapr-0.la lrwxrwxrwx 1 stas stas 17 Aug 20 12:19 /home/stas/httpd/prefork/lib/libapr-0.so -> libapr-0.so.0.9.5 lrwxrwxrwx 1 stas stas 26 Aug 20 12:19 /home/stas/httpd/prefork/lib/libapr-0.so.0 -> libapr-0.so.0.9.5-nondebug -rwxr-xr-x 1 stas stas 383263 Aug 20 12:19 /home/stas/httpd/prefork/lib/libapr-0.so.0.9.5 -rwxr-xr-x 1 stas stas 1381266 Sep 30 2003 /home/stas/httpd/prefork/lib/libapr-0.so.0.9.5-debug -rwxr-xr-x 1 stas stas 1379306 Sep 30 2003 /home/stas/httpd/prefork/lib/libapr-0.so.0.9.5-nondebug at least that's how things work on linux. ldd /home/stas/apache.org/mp2-pool/blib/arch/Apache2/auto/APR/APR.so libapr-0.so.0 => /home/stas/httpd/prefork/lib/libapr-0.so.0 (0x40007000) So -lapr-0 links to libapr-0.so.0 which is a symlink to libapr-0.so.0.9.5 I'd suggest to completely nuke /usr/local/apache2, install Apache from scratch and chances are that everything will work fine. You have too many old libs there. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: "make test" in 1.99_16
Dan Wilga wrote: Here's another tidbit: I end up in this same infinite loop if I do "make clean" or "make distclean". Why it's even trying to run httpd and apxs for this, I dunno. That's probably related to the previous issues you've encountered. Please check if you still have them with the current cvs. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: "make test" in 1.99_16
Stas Bekman wrote: Dan Wilga wrote: I'm having two problems with "make test" in 1.99_16. Here's a transcript of what happens: We are now going to configure the Apache-Test framework. This configuration process needs to be done only once. ...and now it goes into an infinite loop, asking me again to confirm httpd and apxs locations. It does the same thing if I actually type "1" at both prompts instead of just hitting return. I checked, and the default paths for these programs are correct. That's the first problem. It was not supposed to need the interactive config, since when you build mod_perl 2.0, A-T already has all the needed information. Please post your lib/Apache/BuildConfig.pm from which A-T takes this info. Wait, first please try the current cvs, I think the current cvs should work better. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: "make test" in 1.99_16
Dan Wilga wrote: I'm having two problems with "make test" in 1.99_16. Here's a transcript of what happens: We are now going to configure the Apache-Test framework. This configuration process needs to be done only once. ...and now it goes into an infinite loop, asking me again to confirm httpd and apxs locations. It does the same thing if I actually type "1" at both prompts instead of just hitting return. I checked, and the default paths for these programs are correct. That's the first problem. It was not supposed to need the interactive config, since when you build mod_perl 2.0, A-T already has all the needed information. Please post your lib/Apache/BuildConfig.pm from which A-T takes this info. The second happens when I try to break out by typing "skip", as instructed: If for some reason you want to skip the test suite, type: skip Please provide a full path to 'httpd' executable or choose from the following options: [1] /usr/sbin/httpd [1] skip Undefined subroutine &Apache::TestConfig::skip_test_suite called at /users2/dwilga/mod_perl-1.99_16/Apache-Test/lib/Apache/TestConfig.pm line 2194, line 1. ++ | Please file a bug report: http://perl.apache.org/bugs/ | ++ make: *** [run_tests] Error 2 It has the effect of quitting the test, but is probably not as elegant as originally intended. Yup, that's a bug I've introduced while moving things around, now fixed in the cvs. Unfortunately we don't have a test suite to test to test A-T configuration process. And until someone writes one, we are doomed to break previously working things :( -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] recirculating (sub)?request output
suppose i wanted to run a subrequest, but instead of outputting the body (or headers, or anything) of that request down the wire, i wanted to snag it for processing in another handler. i tried writing a filter that gathered the content and stuck it in $f->r->prev->notes, but it still flushes the headers of the main request. what would be the most appropriate way to go about doing this kind of thing? cheers dorian -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] a little OT, problem finding libapr
Please send the output of mp2bug as requested before. Done. I just pulled the latest CVS down, same problem. -8<-- Start Bug Report 8<-- 1. Problem Description: [DESCRIBE THE PROBLEM HERE] 2. Used Components and their Configuration: *** mod_perl version 1.9917 *** using /data/src/modperl-2.0/bin/../lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS=> /usr/local/apache2/bin/apxs MP_COMPAT_1X => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 MP_USE_STATIC => 1 *** The httpd binary was not found *** (apr|apu)-config linking info -L/usr/local/apache2/lib -lapr-0 -lm -lcrypt -lresolv -L/usr/local/apache2/lib -laprutil-0 -lexpat *** /usr/local/perl-5.8.5/bin/perl -V Summary of my perl5 (revision 5 version 8 subversion 5) configuration: Platform: osname=netbsd, osvers=1.6.2, archname=i386-netbsd uname='netbsd steel1.stealstopper.com 1.6.2 netbsd 1.6.2 (generic) #0: tue feb 10 21:53:10 utc 2004 [EMAIL PROTECTED]:autobuildnetbsd-1-6-patch002i386objautobuildnetbsd-1-6-patch002srcsysarchi386compilegeneric i386 ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -pipe -I/usr/pkg/include', optimize='-O', cppflags='-fno-strict-aliasing -pipe -I/usr/pkg/include' ccversion='', gccversion='2.95.3 20010315 (release) (NetBSD nb3)', 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 =' -Wl,-rpath,/usr/pkg/lib -Wl,-rpath,/usr/local/lib -L/usr/pkg/lib -L/usr/local/lib' libpth=/usr/pkg/lib /usr/local/lib /usr/lib libs=-lm -lcrypt -lutil -lc -lposix perllibs=-lm -lcrypt -lutil -lc -lposix libc=/usr/lib/libc.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-R/usr/local/perl-5.8.5/lib/5.8.5/i386-netbsd/CORE' cccdlflags='-DPIC -fPIC ', lddlflags='--whole-archive -shared -L/usr/pkg/lib -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under netbsd Compiled at Aug 25 2004 14:17:37 %ENV: PERL_LWP_USE_HTTP_10="1" @INC: /usr/local/perl-5.8.5/lib/5.8.5/i386-netbsd /usr/local/perl-5.8.5/lib/5.8.5 /usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd /usr/local/perl-5.8.5/lib/site_perl/5.8.5 /usr/local/perl-5.8.5/lib/site_perl /usr/local/perl-5.8.4 /usr/local/perl-5.8.1 . *** Packages of interest status: Apache::Request: - CGI: 3.05 LWP: 5.800 mod_perl : 1.9917 3. This is the core dump trace: (if you get a core dump): [CORE TRACE COMES HERE] This report was generated by ./mp2bug on Fri Aug 27 00:16:18 2004 GMT. -8<-- End Bug Report --8<-- -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl 1.99_16 tests fail on OpenBSD due to low open files limit
Ken Simpson wrote: FYI, I just discovered after much pain and suffering that the mod_perl test suite fails to run on OpenBSD 3.5 because it tries to open more than 64 files at once. [...] Perl can't load TestFilter/in_str_consume.pm because it can't open the file -- as evidenced in the ktrace dump: 16641 httpdNAMI "/export/src/mod_perl-1.99_16/t/lib/TestFilter/in_str_consume.pmc" 16641 httpdRET stat -1 errno 2 No such file or directory 16641 httpdCALL open(0x3cdae100,0,0) 16641 httpdRET open -1 errno 24 Too many open files This problem can be resolved by increasing the open file limit to 128: $ ulimit -n 128 I hope this helps someone down the road! Thanks Ken. I've adopted your report in the troubleshooting section: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#Can_t_locate_F_TestFilter_in_str_consume_pm__in_C__INC -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[ANNOUNCE] Cache::FastMmap 1.08
Apparently a few people on this list use the module, so I thought I'd just announce here... Mostly just removes the requirement on perl 5.8 for installation because apparently the utf-8 support works fine under 5.6 anyway. http://search.cpan.org/~robm/Cache-FastMmap-1.08/ Rob -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] a little OT, problem finding libapr
Carl Brewer wrote:
Stas Bekman wrote:
Carl, remember to always file a proper bug report and save yourself
and us time. The report includes the info we need. Other than that,
please send us the output of:
I would, except I don't think it's a bug report, it's probably a
stuff-up at my end :)
don't let the "bug" word mislead you. The report includes information w/o
which we can't help you even if the problem is on your side.
ldd /usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/auto/APR/APR.so
steel1: {15} ldd
/usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/auto/AP
APR.so
/usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/auto/APR/APR.so:
-lapr-0.9 => not found
-lm.0 => /usr/lib/libm387.so.0
-lm.0 => /usr/lib/libm.so.0
-lcrypt.0 => /usr/lib/libcrypt.so.0
-lresolv.1 => /usr/lib/libresolv.so.1
-laprutil-0.9 => not found
-lexpat.5 => /usr/pkg/lib/libexpat.so.5
ls -l /usr/local/apache2/lib/libapr-0.so.9
steel1: {16} ls -l /usr/local/apache2/lib/libapr-0.so.9
lrwxrwxr-x 1 root wheel 15 Aug 25 08:42
/usr/local/apache2/lib/libapr-0.so.9 -> libapr-0.so.9.5
Obviously the lapr being missing is a problem!
Please send the output of mp2bug as requested before.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: reading from STDIN on startup
> > I'm also confused about the documentation for PerlRequire. It say's that > > files loaded via PerlRequire are compiled only once, but my startup.pl file > > is definitly being compiled twice. > > My impression is that it's just broken, since I recall seeing the same > behavior. This has come up before, but no one seems to know quite why > it doesn't work. It's typically not much of an issue since the average > startup.pl just does 'use Foo', and the use statement will only load Foo > once. > > As a workaround, see the $Apache::Server::ReStarting variable in the > docs or load your startup.pl like this: > use startup.pl; > > - Perrin > I tried the Apache::Server::Starting/Restarting variables. When using apachectl startssl, Starting =1 both times that startup.pl is compiled, and Restarting =0 on both, so those don't work as they should either I guess. What does work is just writing out the value to a temp file on the first compile, and reading it on the second then deleting it. Kind of a hack but better than just having the password hard coded in the config file. Chris > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > > -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] a little OT, problem finding libapr
Stas Bekman wrote:
Carl, remember to always file a proper bug report and save yourself and
us time. The report includes the info we need. Other than that, please
send us the output of:
I would, except I don't think it's a bug report, it's probably a
stuff-up at my end :)
ldd /usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/auto/APR/APR.so
steel1: {15} ldd
/usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/auto/AP
APR.so
/usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/auto/APR/APR.so:
-lapr-0.9 => not found
-lm.0 => /usr/lib/libm387.so.0
-lm.0 => /usr/lib/libm.so.0
-lcrypt.0 => /usr/lib/libcrypt.so.0
-lresolv.1 => /usr/lib/libresolv.so.1
-laprutil-0.9 => not found
-lexpat.5 => /usr/pkg/lib/libexpat.so.5
ls -l /usr/local/apache2/lib/libapr-0.so.9
steel1: {16} ls -l /usr/local/apache2/lib/libapr-0.so.9
lrwxrwxr-x 1 root wheel 15 Aug 25 08:42
/usr/local/apache2/lib/libapr-0.so.9 -> libapr-0.so.9.5
Obviously the lapr being missing is a problem!
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] a little OT, problem finding libapr
Carl Brewer wrote:
After upgrading to Stas' latest MP2 stuff a few days ago,
I started seeing the following error on a perl script that's
not running through mp2, which I thought a little odd!
steel1: {12} /data/www/aboc/utils/session_cleanup.pl
Can't load
'/usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/auto/APR/APR.so'
for module APR: Shared object "libapr-0.so.9" not found at
/usr/local/perl-5.8.5/lib/5.8.5/i386-netbsd/DynaLoader.pm line 230.
at /usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/APR/Bucket.pm
line 23
Compilation failed in require at
/usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/APR/Bucket.pm line
23.
BEGIN failed--compilation aborted at
/usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/APR/Bucket.pm line
23.
Compilation failed in require at /data/www/aboc/lib/CB.pm line 378.
BEGIN failed--compilation aborted at /data/www/aboc/lib/CB.pm line 378.
Compilation failed in require at /data/www/aboc/utils/session_cleanup.pl
line 7.
BEGIN failed--compilation aborted at
/data/www/aboc/utils/session_cleanup.pl line 7.
This is on NetBSD 1.6.2, and libapr-0.so.9 exists :
steel1: {13} locate libapr-0.so.9
/usr/local/apache2/lib/libapr-0.so.9
/usr/local/apache2/lib/libapr-0.so.9.2
/usr/local/apache2/lib/libapr-0.so.9.3
/usr/local/apache2/lib/libapr-0.so.9.4
/usr/local/apache2/lib/libapr-0.so.9.5
The offending line in CB.pm is :
use APR::Bucket ();
Which is obviously Apache stuff, so it's probably been affected by
something. I don't understand why it's not seeing the library
though?
I've tried upgrading to a fresh install of perl 5.8.5 (I was
running 5.8.4) and the latest libapreq2 from Joe this morning,
and recompiing & reinstalling apache2 (2.0.50) hoping that
something in one of those installs would fix whatever's not
looking for the library in the right place, but to no avail.
Any suggestions?
Carl, remember to always file a proper bug report and save yourself and us
time. The report includes the info we need. Other than that, please send
us the output of:
ldd /usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/auto/APR/APR.so
and
ls -l /usr/local/apache2/lib/libapr-0.so.9
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] a little OT, problem finding libapr
After upgrading to Stas' latest MP2 stuff a few days ago,
I started seeing the following error on a perl script that's
not running through mp2, which I thought a little odd!
steel1: {12} /data/www/aboc/utils/session_cleanup.pl
Can't load
'/usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/auto/APR/APR.so'
for module APR: Shared object "libapr-0.so.9" not found at
/usr/local/perl-5.8.5/lib/5.8.5/i386-netbsd/DynaLoader.pm line 230.
at /usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/APR/Bucket.pm
line 23
Compilation failed in require at
/usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/APR/Bucket.pm line 23.
BEGIN failed--compilation aborted at
/usr/local/perl-5.8.5/lib/site_perl/5.8.5/i386-netbsd/APR/Bucket.pm line 23.
Compilation failed in require at /data/www/aboc/lib/CB.pm line 378.
BEGIN failed--compilation aborted at /data/www/aboc/lib/CB.pm line 378.
Compilation failed in require at /data/www/aboc/utils/session_cleanup.pl
line 7.
BEGIN failed--compilation aborted at
/data/www/aboc/utils/session_cleanup.pl line 7.
This is on NetBSD 1.6.2, and libapr-0.so.9 exists :
steel1: {13} locate libapr-0.so.9
/usr/local/apache2/lib/libapr-0.so.9
/usr/local/apache2/lib/libapr-0.so.9.2
/usr/local/apache2/lib/libapr-0.so.9.3
/usr/local/apache2/lib/libapr-0.so.9.4
/usr/local/apache2/lib/libapr-0.so.9.5
The offending line in CB.pm is :
use APR::Bucket ();
Which is obviously Apache stuff, so it's probably been affected by
something. I don't understand why it's not seeing the library
though?
I've tried upgrading to a fresh install of perl 5.8.5 (I was
running 5.8.4) and the latest libapreq2 from Joe this morning,
and recompiing & reinstalling apache2 (2.0.50) hoping that
something in one of those installs would fix whatever's not
looking for the library in the right place, but to no avail.
Any suggestions?
thanks!
Carl
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [SITE][mp2] Associating an interpreter pool with a directory
Perrin Harkins wrote: On Thu, 2004-08-26 at 16:15, Stas Bekman wrote: It works with prefork MPM too as long as perl has ithreads enabled, it's exercised in the test suite. That wouldn't really be the same thing though, would it? For example, every child process would have a different $count variable and a different instance of the singleton object. That's correct, Perrin. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: reading from STDIN on startup
On Thu, 2004-08-26 at 16:28, Chris Ochs wrote: > I'm also confused about the documentation for PerlRequire. It say's that > files loaded via PerlRequire are compiled only once, but my startup.pl file > is definitly being compiled twice. My impression is that it's just broken, since I recall seeing the same behavior. This has come up before, but no one seems to know quite why it doesn't work. It's typically not much of an issue since the average startup.pl just does 'use Foo', and the use statement will only load Foo once. As a workaround, see the $Apache::Server::ReStarting variable in the docs or load your startup.pl like this: use startup.pl; - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [SITE][mp2] Associating an interpreter pool with a directory
On Thu, 2004-08-26 at 16:15, Stas Bekman wrote: > It works with prefork MPM too as long as perl has ithreads enabled, it's > exercised in the test suite. That wouldn't really be the same thing though, would it? For example, every child process would have a different $count variable and a different instance of the singleton object. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: reading from STDIN on startup
I'm also confused about the documentation for PerlRequire. It say's that files loaded via PerlRequire are compiled only once, but my startup.pl file is definitly being compiled twice. Maybe there is something else in my config that would cause it? Or am I misunderstanding something? Chris - Original Message - From: "Chris Ochs" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 26, 2004 12:57 PM Subject: reading from STDIN on startup > > this is apache 1.3.29/mod_perl 1.28 > > I use connect_on_init for database connections, and I want to read the > password from STDIN instead of putting the password into the startup.pl > file. I was reading that apache initializes the modules twice when it > starts up, but I'm confused by the behavior I am getting with the following > code. It appears to run twice, with the first run setting $my::dbpass fine, > and on the second it contains nothing. I can't see how to get $my::dbpass > to persist through the second init. Any ideas on how to do this? > > Chris > > $my::dbpass = unless defined $my::dbpass; > chop $my::dbpass; > > # for testing purposes >open(OUT, ">>/tmp/db"); >print OUT "$my::dbpass"; >close OUT; > > > > > > > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > > -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: MP2 output filters
Jared Cook wrote: I am trying to implement a stream output filter and am having a little problem. I need to have the INCLUDES filter process the output first and then send it to the mod_perl filter. I used PerlSetOutputFilter INCLUDES, and I think it is getting the data before it goes to my filter. Now my problem: It looks like every include that gets processed starts a new stream to my filter. I need mod_include to process all the includes and THEN send the completed flat document to my mod_perl filter. Is this possible? Please advise. No, it's not. You filter should be able to cope with data coming in in chunks. Please read: http://perl.apache.org/docs/2.0/user/handlers/filters.html#Multiple_Invocations_of_Filter_Handlers See an example on how to maintain state between filter invocations here: http://perl.apache.org/docs/2.0/user/handlers/filters.html#Stream_oriented_Output_Filters -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [SITE][mp2] Associating an interpreter pool with a directory
Perrin Harkins wrote: [EMAIL PROTECTED] wrote: Is it within the scope of mod_perl2 to duplicate its interpreter pool framework? Intention: To have separate interpreter pools for directories /test1 and /test2 Read http://perl.apache.org/docs/2.0/user/config/config.html It looks like you would just need to do this: PerlOptions +Clone PerlInterpStart 2 PerlInterpMax 2 PerlOptions +Clone PerlInterpStart 2 PerlInterpMax 2 You would have to run threads of course, e.g. the "worker" MPM. I run in pre-fork MPM, so I haven't really played with these options yet. It works with prefork MPM too as long as perl has ithreads enabled, it's exercised in the test suite. -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
reading from STDIN on startup
this is apache 1.3.29/mod_perl 1.28 I use connect_on_init for database connections, and I want to read the password from STDIN instead of putting the password into the startup.pl file. I was reading that apache initializes the modules twice when it starts up, but I'm confused by the behavior I am getting with the following code. It appears to run twice, with the first run setting $my::dbpass fine, and on the second it contains nothing. I can't see how to get $my::dbpass to persist through the second init. Any ideas on how to do this? Chris $my::dbpass = unless defined $my::dbpass; chop $my::dbpass; # for testing purposes open(OUT, ">>/tmp/db"); print OUT "$my::dbpass"; close OUT; -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: libapreq2 versus everything else
Ken Burcham <[EMAIL PROTECTED]> writes: > I heartily agree... it would have saved me a lot of time coming into > mod_perl2 land... The reason it isn't in mp2 is IMO largely a matter of timing (and a bit of politics). apreq-dev wanted to get the C stuff included in httpd's distro, that way mp2 could provide the wrappers for it. However apreq2 was just getting started when httpd-2.0 was declared stable, so the earliest inclusion point apreq-dev could hope for was the 2.2 line. We're stable enough now to be considering 2.04-dev as the final developer's release (more on that soon), so it's really up to the httpd community to determine whether or not httpd-2.2 users will benefit from it. -- Joe Schaefer -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: libapreq2 versus everything else
I heartily agree... it would have saved me a lot of time coming into mod_perl2 land... ken. On Aug 25, 2004, at 11:30 PM, Markus Wichitill wrote: I think adding Apache::Request to the mod_perl distribution might save a few souls from going PHP. Having all these fancy APIs but not basic stuff like parameter accessors probably scares some newcomers away. But since this was mostly true for MP1 already, I guess this must have been rejected long ago. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
