Apache::DBI
Hello, every body
I can run the following subroutine in DBI, but Apache::DBI...
use DBI;
sub connect{
$dbh = DBI-connect(dbi:Pg:dbname=test, canis,3dsadasz);
$sth = $dbh-prepare(SELECT clave, denominacion FROM Marca)
|| die $dbh-errstr;
$sth-execute() || die $sth-errstr;
while(my $row = $sth-fetch){
my($clave, $nombre) = @$row;
print clave = $clave, denominacion = $nombre\n;
}
$dbh-disconnect;
}
and I have this log...
[Thu Aug 28 12:36:44 2003] [error] (2)No such file or directory: mod_mime_magic:
can't read magic file /etc/apache-perl/share/magic
[Thu Aug 28 12:36:45 2003] [notice] Apache/1.3.26 (Unix) Debian GNU/Linux
mod_perl/1.26 configured -- resuming normal operations
[Thu Aug 28 12:36:45 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache/suexec)
[Thu Aug 28 12:36:45 2003] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Thu Aug 28 12:37:03 2003] null: DBI-connect(dbname=test) failed: FATAL 1:
IDENT authentication failed for user canis at /var/lib/perl/JCVA/Conexion.pm
line 11
[Thu Aug 28 12:37:03 2003] [error] Can't call method prepare on an undefined
value at /var/lib/perl/JCVA/Conexion.pm line 13.
Somedody knows if the user must be registered in some configuration file?
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DBI
It looks like your PostgreSQL installation is trying to do IDENT
authentication, instead of MD5. So, it's checking the user your script is
running as, and trusting that since you managed to log on with your
username/password already, it'll trust you to log into the database.
While this isn't strictly an Apache problem, but rather a database problem,
here's what's probably the matter. In your /var/lib/pgsql/data/pg_hba.conf
file, you probably have the default:
local all all trust
I would suggest changing this to something like:
local all all md5
or make it IP based:
host allall1.2.3.4255.255.255.255 md5
you get the idea. That way, it'll obey the username/password that you supply.
On Thursday 28 August 2003 04:28 pm, wrote:
Hello, every body
I can run the following subroutine in DBI, but Apache::DBI...
use DBI;
sub connect{
$dbh = DBI-connect(dbi:Pg:dbname=test, canis,3dsadasz);
$sth = $dbh-prepare(SELECT clave, denominacion FROM Marca)
|| die $dbh-errstr;
$sth-execute() || die $sth-errstr;
while(my $row = $sth-fetch){
my($clave, $nombre) = @$row;
print clave = $clave, denominacion = $nombre\n;
}
$dbh-disconnect;
}
and I have this log...
[Thu Aug 28 12:36:44 2003] [error] (2)No such file or directory:
mod_mime_magic: can't read magic file /etc/apache-perl/share/magic
[Thu Aug 28 12:36:45 2003] [notice] Apache/1.3.26 (Unix) Debian GNU/Linux
mod_perl/1.26 configured -- resuming normal operations
[Thu Aug 28 12:36:45 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache/suexec)
[Thu Aug 28 12:36:45 2003] [notice] Accept mutex: sysvsem (Default:
sysvsem) [Thu Aug 28 12:37:03 2003] null: DBI-connect(dbname=test) failed:
FATAL 1: IDENT authentication failed for user canis at
/var/lib/perl/JCVA/Conexion.pm line 11
[Thu Aug 28 12:37:03 2003] [error] Can't call method prepare on an
undefined value at /var/lib/perl/JCVA/Conexion.pm line 13.
Somedody knows if the user must be registered in some configuration file?
--
/* Michael A. Nachbaur [EMAIL PROTECTED]
* http://nachbaur.com/pgpkey.asc
*/
Another world, another day, another dawn.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::DBI
I can run the following code with DBI
but in Apache::DBI.
#!/usr/bin/perl -w
use DBI;
sub connect{
$dbh = DBI-connect(dbi:Pg:dbname=test, canis,$password);
$sth = $dbh-prepare(SELECT clave, denominacion FROM Marca)
|| die $dbh-errstr;
$sth-execute() || die $sth-errstr;
while(my $row = $sth-fetch){
my($clave, $nombre) = @$row;
print clave = $clave, denominacion = $nombre\n;
}
$dbh-disconnect;
I have this log...
[Thu Aug 28 12:36:44 2003] [error] (2)No such file or directory: mod_mime_magic:
can't read magic file /etc/apache-perl/share/magic
[Thu Aug 28 12:36:45 2003] [notice] Apache/1.3.26 (Unix) Debian GNU/Linux
mod_perl/1.26 configured -- resuming normal operations
[Thu Aug 28 12:36:45 2003] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache/suexec)
[Thu Aug 28 12:36:45 2003] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Thu Aug 28 12:37:03 2003] null: DBI-connect(dbname=test) failed: FATAL 1:
IDENT authentication failed for user canis at /var/lib/perl/JCVA/Conexion.pm
line 11
[Thu Aug 28 12:37:03 2003] [error] Can't call method prepare on an undefined
value at /var/lib/perl/JCVA/Conexion.pm line 13.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
SOAP::Lite in mod_perl...
Hi All,
I'm having a weird problem using SOAP::Lite in one of my mod_perl
modules.
A snippet of my code is:
sub _dispatch {
my $self = shift;
my $proxy = http://our.stats.server.com.au/soap/script.cgi;;
my $soap = SOAP::Lite-uri('NetChantStats')-proxy($proxy)-on_debug(sub{warn @_});
###
my $result = $soap-getDetails(chris);
###
if (! $result-fault) {
my $result_str = $result-result();
my $result_ref = eval $result_str;
#
#
#
if (! ref($result_ref)) { return $self-setError(Dispatch Error: $result_str); }
else{ return $result_ref; }
}
else {
my $error = join (', ', $result-faultcode, $result-faultstring);
return $self-setError($error);
}
}
The above code works perfectly on:
* On dev server in a standalone script
* On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c
DAV/1.0.3 mod_perl/1.27
* Our live server as a standalong script
The code does not work on our live server under:
* Live Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.6c DAV/1.0.3
mod_perl/1.28
===
The code is acting weird on the live server on the line (only under mod_perl):
my $result = $soap-getDetails(chris);
If i return just before the above line, the return happens and i get a document
produced, but the line above just seems to make the server disappear.
What i mean by disappear is that there is nothing in the access log however, the
error log
does contain the debugging information from the SOAP::Lite module (as i have the
on_debug method
printing stuff).
The server definitely does not die and produce a 500 server error, it literally just
disappears, almost as if a kill -9 was given to the relevant httpd thread as there is
nothing at all written to the access log...!!!
Has anyone come across a situation like the above? Any hints on how i can debug the
above would also
be greatly appreciated...
thanks,
simran.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
simran wrote: The above code works perfectly on: * On dev server in a standalone script * On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.27 * Our live server as a standalong script The code does not work on our live server under: * Live Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.28 It could be the same change in apache 1.3.28 that is causing problems for Bricolage. See this bug report: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22805 To verify it, you can build a copy of your dev server that is identical except for using apache 1.3.28 and see if that fails as well. If you're feeling ambitious, you can try the patch attached to that bug report. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
using -| construct
I have a web service that need to get stuff from the system and is
using the following subroutine to retrieve info.
sub systeminfo {
if (open(FROMADMIN,-|)) { # parent
undef local $/;
my $rv = FROMADMIN; # get response
close FROMADMIN;
return $rv;
}
else {
unless (open STDERR, 'STDOUT') {
print STDERR can't dup STDERR to STDOUT: $!;
exit 1;
}
my($command,$stdin) = @_;
open(ADMIN,'|'. $command);
print ADMIN $stdin
if $stdin;
close ADMIN;
exit 0;
}
}
This works fine for command line exection and from cgi but fails in
modperl (apache 1x).
The problem is that the initial read pipe apparently fails to open
under modperl.
Is there a workaround for this? or am I just missing something
simple?
Michael
[EMAIL PROTECTED]
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: using -| construct
Michael wrote:
I have a web service that need to get stuff from the system and is
using the following subroutine to retrieve info.
sub systeminfo {
if (open(FROMADMIN,-|)) { # parent
[...]
This works fine for command line exection and from cgi but fails in
modperl (apache 1x).
The problem is that the initial read pipe apparently fails to open
under modperl.
Is there a workaround for this? or am I just missing something
simple?
Use IPC::Run?
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Thanks Perrin. I'll try a recompile with Apache 1.27 as suggested... not brave enough to eventually put a patched 1.28 on our live server yet :-) simran. On Fri, 2003-08-29 at 11:25, Perrin Harkins wrote: simran wrote: The above code works perfectly on: * On dev server in a standalone script * On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.27 * Our live server as a standalong script The code does not work on our live server under: * Live Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.28 It could be the same change in apache 1.3.28 that is causing problems for Bricolage. See this bug report: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22805 To verify it, you can build a copy of your dev server that is identical except for using apache 1.3.28 and see if that fails as well. If you're feeling ambitious, you can try the patch attached to that bug report. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Hi Perrin, I just recompiled everything with 1.27 (and relevant mod_ssl module) and everything is working wonderfully again. thankyou again every so much for your help, i had been struggling with it for days... simran. Thanks Perrin. I'll try a recompile with Apache 1.27 as suggested... not brave enough to eventually put a patched 1.28 on our live server yet :-) simran. On Fri, 2003-08-29 at 11:25, Perrin Harkins wrote: simran wrote: The above code works perfectly on: * On dev server in a standalone script * On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.27 * Our live server as a standalong script The code does not work on our live server under: * Live Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.28 It could be the same change in apache 1.3.28 that is causing problems for Bricolage. See this bug report: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22805 To verify it, you can build a copy of your dev server that is identical except for using apache 1.3.28 and see if that fails as well. If you're feeling ambitious, you can try the patch attached to that bug report. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Hi guys, On Thu, 28 Aug 2003, Perrin Harkins wrote: simran wrote: The above code works perfectly on: * On dev server in a standalone script * On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.27 * Our live server as a standalong script The code does not work on our live server under: * Live Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.28 Have you mentioned this to Philippe Chiasson? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Ged Haywood wrote: Hi guys, On Thu, 28 Aug 2003, Perrin Harkins wrote: simran wrote: The above code works perfectly on: * On dev server in a standalone script * On our dev server under: Apache/1.3.27 (Unix) mod_ssl/2.8.12 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.27 * Our live server as a standalong script The code does not work on our live server under: * Live Server: Apache/1.3.28 (Unix) mod_ssl/2.8.15 OpenSSL/0.9.6c DAV/1.0.3 mod_perl/1.28 Have you mentioned this to Philippe Chiasson? Beg your pardon, Ged? What this has to do with Philippe? Perrin has already replied that it's a bug in Apache 1.3.28: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22805 __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Hi Stas, On Fri, 29 Aug 2003, Stas Bekman wrote: Ged Haywood wrote: Have you mentioned this to Philippe Chiasson? Beg your pardon, Ged? What this has to do with Philippe? Wasn't he organising the release of mod_perl 1.28? If people are moving to a 1.3.28/1.28 combination, I would expect his mailbox to start filling up... 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SOAP::Lite in mod_perl...
Have you mentioned this to Philippe Chiasson? Beg your pardon, Ged? What this has to do with Philippe? Wasn't he organising the release of mod_perl 1.28? He was a release manager, not a person to blame, even if there was a problem with 1.28, which is certainly not the case. If people are moving to a 1.3.28/1.28 combination, I would expect his mailbox to start filling up... That shouldn't be the case, really. One of us wears the release manager hat once in awhile, but we all stand behind each release. All the bugs are to be reported here, and not to the person who has happened to put it on CPAN. We are slowly working on fixing CPAN to support role accounts, where several people can maintain the same package, taking turns on doing releases. And no matter who releases it, all the bug reports will go to one specified place, not the last release manager's mail box. For mod_perl specifically we want to have a CPAN-id modperl where all the packages maintained by the development team will go. That CPAN-id will have an email address of this list, which will protect the last release manager from misdirected email. The packages will also be put into that CPAN-id's homedir on CPAN, and not release manager's one. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
nntp interface to modperl list archives is avalable
I was delighted to discover an nntp gateway news.gmane.org which carries the following three archives: docs-dev: nntp://news.gmane.org/gmane.comp.apache.mod-perl.devel modperl:nntp://news.gmane.org/gmane.comp.apache.mod-perl apreq-dev: nntp://news.gmane.org/gmane.comp.apache.apreq They are much more useful than the normal archives, though it seems that you can go back only 1 year. I have updated the online http://perl.apache.org/maillist/ docs, if you know of other nntp interfaces to modperl lists, please let me know. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: SOAP::Lite in mod_perl...
On an unrelated note SOAP::Lite developement seems to have gone quite to me anyway. Greg -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[OT] Request for Extreme Programming with Perl Experiences
Apologies for the off-topic post... I'm looking for stories, annecdotes, comparisons, etc. from people who are using extreme programming using Perl. Even if you are using only some of the practices, such as, testing, coding, and refactoring, your input will be useful. The good, the bad, the ugly. Anything that is about a real XP experience using Perl in real-world situations. I would especially like to hear about large application development in a commercial environment. The stories are for my book: Extreme Programming with Perl. If you want to keep your name and company anonymous, please let me know. If I decide to include your story, you'll get to review the text before I submit it to my editor. If you want to reply to a list, send it to the extremeperl Yahoo group. Or, you can send it directly to me (nagler) at bivio.biz, and I'll keep it confidential. Thanks, Rob -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
where to find request object in mod_perl2
Hello all, I have perl programs running under Apache::Registry. Now I need to switch to mod_perl2 and can not find request object. I used to get as $r = Apache-request; But this does not work under mod_perl2. Please advise how do something similar and avoid big changes in scripts. Thank you in advance, Igor -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Problems Installing On Debian - Or Not
Hi All, It looked like the Debian install problems were back. [EMAIL PROTECTED]:~/temp/modperl-2.0$ perl Makefile.PL * WARNING * Your Perl is configured to link against libgdbm, but libgdbm.so was not found. You could just symlink it to /usr/lib/libgdbm.so.1.7.3 * WARNING * !!! Unable to open /mnt/general/temp/modperl-2.0/../../home/craig/temp/mod_perl-1.99_09/ap_release.h: No such file or directory !!! Unable to determine server version, aborting. !!! Please specify MP_APXS or MP_AP_PREFIX. I thought this was a bit strange, look at the path where it is trying to find my apache include dir. It should be looking in /usr/include/apache2/ Anyway, I do what it says... [EMAIL PROTECTED]:~/temp/modperl-2.0$ perl Makefile.PL MP_AP_PREFIX=/usr/include/apache2/ Reading Makefile.PL args from @ARGV MP_AP_PREFIX = /usr/include/apache2 * WARNING * Your Perl is configured to link against libgdbm, but libgdbm.so was not found. You could just symlink it to /usr/lib/libgdbm.so.1.7.3 * WARNING * !!! invalid MP_AP_PREFIX: include/ directory not found in /usr/include/apache2 Looked at first like I would have to frig the script... After analysing Build.pm, I noticed it was using a load of crap data from my old installation in /usr/local/lib/perl/5.8.0/Apache/BuildConfig.pm After deleting this file, i had to delete what i had got from cvs, and redownload. The second time round I ran into more problems... [EMAIL PROTECTED]:~/temp/modperl-2.0$ perl Makefile.PL * WARNING * Your Perl is configured to link against libgdbm, but libgdbm.so was not found. You could just symlink it to /usr/lib/libgdbm.so.1.7.3 * WARNING * !!! Unable to determine server version, aborting. !!! Please specify MP_APXS or MP_AP_PREFIX. Ok, so i specify the MP_AP_PREFIX option, since that was mentioned in the INSTALL file too. [EMAIL PROTECTED]:~/temp/modperl-2.0$ perl Makefile.PL MP_AP_PREFIX=/usr/include/apache2/ Reading Makefile.PL args from @ARGV MP_AP_PREFIX = /usr/include/apache2 * WARNING * Your Perl is configured to link against libgdbm, but libgdbm.so was not found. You could just symlink it to /usr/lib/libgdbm.so.1.7.3 * WARNING * !!! invalid MP_AP_PREFIX: include/ directory not found in /usr/include/apache2 Ah that problem again... SOLUTION: perl Makefile.PL MP_APXS=/usr/bin/apxs2 All problems went away. Problems occur in debian if the MP_AP_PREFIX is used because it expects a /include dir to be present. but if the MP_APXS option is not used, the MP_AP_PREFIX is one of the tempting recommendations by the script. The question here is, should the script have detected /usr/bin/apxs2 ? -- Craig Shelley [EMAIL PROTECTED] I hope the formatting of this email didn't come out too bad. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: where to find request object in mod_perl2
Igor Ivoilov wrote: Hello all, I have perl programs running under Apache::Registry. Now I need to switch to mod_perl2 and can not find request object. I used to get as $r = Apache-request; But this does not work under mod_perl2. http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_request_ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re[2]: [mp2] make test failed
Hi! My guess is that you've been hit by this Apache problem: http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile As the URL above suggests, try to add 'EnableSendfile On' somewhere in t/conf/httpd.conf and rerun: t/TEST -v filter/in_bbs_msg.t hooks/trans.t don't run 'make test' as it'll rewrite t/conf/httpd.conf, use t/TEST instead. I wonder why http://httpd.apache.org/docs-2.0/mod/core.html#enablesendfile says that it's on by default. SB Argh, I confused simply use the EnableSendfile directive as to be turned on. SB It should be: SBEnableSendfile Off SB of course. I guessed :-) Thank you, but your advice helped with hooks/trans.t only, filter/in_bbs_msg.t is still failed: t/TEST -v filter/in_bbs_msg.t *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -v 'filter/in_bbs_msg.t' *** root mode: changing the fs ownership to 'nobody' (99:99) /usr/local/httpd_perl/bin/httpd -d /usr/src/httpd_perl/mod_perl-1.99_09/t -f /usr/src/httpd_perl/mod_perl-1.99_09/t/conf/htt pd.conf -DAPACHE2 using Apache/2.0.47 (prefork MPM) waiting for server to start: .[Fri Aug 29 18:10:56 2003] [info] 20 Apache:: modules loaded [Fri Aug 29 18:10:56 2003] [info] 3 APR:: modules loaded [Fri Aug 29 18:10:56 2003] [info] base server + 8 vhosts ready to run tests .. waiting for server to start: ok (waited 2 secs) server www.myhost.ru:8529 started server www.myhost.ru:8530 listening (TestProtocol::echo_filter) server www.myhost.ru:8531 listening (TestProtocol::echo) server www.myhost.ru:8532 listening (TestPreConnection::note) server www.myhost.ru:8533 listening (TestFilter::in_str_msg) server www.myhost.ru:8534 listening (TestFilter__both_str_con_add) server www.myhost.ru:8535 listening (TestFilter::in_bbs_msg) server www.myhost.ru:8536 listening (TestDirective::perlmodule) server www.myhost.ru:8537 listening (TestDirective::perlrequire) server www.myhost.ru:8538 listening (TestDirective::perlloadmodule4) server www.myhost.ru:8539 listening (TestDirective::perlloadmodule5) server www.myhost.ru:8540 listening (TestDirective::perlloadmodule3) server www.myhost.ru:8541 listening (TestDirective::perlloadmodule6) filter/in_bbs_msg# connecting to www.myhost.ru:8535 server side has failed (response code: 404), see t/logs/error_log for more details dubious Test returned status 29 (wstat 7424, 0x1d00) *** server www.myhost.ru:8529 shutdown !!! error running tests (please examine t/logs/error_log) -- [Fri Aug 29 18:10:56 2003] [info] mod_unique_id: using ip addr 127.0.0.1 END in modperl_extra.pl, pid=26270 [Fri Aug 29 18:10:57 2003] [notice] Digest: generating secret for digest authentication ... [Fri Aug 29 18:10:57 2003] [notice] Digest: done [Fri Aug 29 18:10:57 2003] [info] mod_unique_id: using ip addr 127.0.0.1 [Fri Aug 29 18:10:58 2003] [notice] Apache/2.0.47 (Unix) mod_perl/1.99_09 Perl/v5.8.0 DAV/2 configured -- resuming normal ope rations [Fri Aug 29 18:10:58 2003] [info] Server built: Aug 28 2003 18:59:50 [Fri Aug 29 18:10:58 2003] [debug] prefork.c(1037): AcceptMutex: sysvsem (default: sysvsem) [Fri Aug 29 18:10:58 2003] [error] [client 127.0.0.1] File does not exist: /usr/src/httpd_perl/mod_perl-1.99_09/t/htdocs/inpu t_filter.html [Fri Aug 29 18:10:58 2003] [error] server reached MaxClients setting, consider raising the MaxClients setting [Fri Aug 29 18:10:58 2003] [info] Child process pid=26290 is exiting [Fri Aug 29 18:10:58 2003] [info] removed PID file /usr/src/httpd_perl/mod_perl-1.99_09/t/logs/httpd.pid (pid=26289) [Fri Aug 29 18:10:58 2003] [notice] caught SIGTERM, shutting down END in modperl_extra.pl, pid=26289 I've used standard distributive. Any ideas why I have no input_filter.html ? -- Alan Rafagudinov E-mail: [EMAIL PROTECTED] | [EMAIL PROTECTED] Homepage: http://www.rafagudinov.com Phone: +7(926)22-5 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: where to find request object in mod_perl2
The doc you reference says that Apache-request should be avoided because it is expensive. But does it in fact work? -Paul On Fri, 29 Aug 2003 10:17:57 -0700, Stas Bekman [EMAIL PROTECTED] wrote: Igor Ivoilov wrote: Hello all, I have perl programs running under Apache::Registry. Now I need to switch to mod_perl2 and can not find request object. I used to get as $r = Apache-request; But this does not work under mod_perl2. http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_request_ __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: using -| construct
On Thu, Aug 28, 2003 at 06:43:42PM -0700, Stas Bekman wrote:
Michael wrote:
I have a web service that need to get stuff from the system and is
using the following subroutine to retrieve info.
sub systeminfo {
if (open(FROMADMIN,-|)) { # parent
[...]
This works fine for command line exection and from cgi but fails in
modperl (apache 1x).
The problem is that the initial read pipe apparently fails to open
under modperl.
Is there a workaround for this? or am I just missing something
simple?
Use IPC::Run?
Or System2?
--
Brian 'you Bastard' Reichert[EMAIL PROTECTED]
37 Crystal Ave. #303Daytime number: (603) 434-6842
Derry NH 03038-1713 USA BSD admin/developer at large
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: where to find request object in mod_perl2
Paul G. Weiss wrote: The doc you reference says that Apache-request should be avoided because it is expensive. But does it in fact work? Yes. Have you actually read it? That section also explains when it's available. Igor said: this does not work under mod_perl2, without showing any error messages or explaining what kind of problem he has. On Fri, 29 Aug 2003 10:17:57 -0700, Stas Bekman [EMAIL PROTECTED] wrote: Igor Ivoilov wrote: Hello all, I have perl programs running under Apache::Registry. Now I need to switch to mod_perl2 and can not find request object. I used to get as $r = Apache-request; But this does not work under mod_perl2. http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache_E_gt_request_ __ 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 -- __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Hi All,
On Wed, 2003-08-27 at 02:33, Geoffrey Young wrote:
hi craig.
before we continue, please try the latest cvs (without the patch I sent)
and see if your stuff segfaults there. if not, at least we know we've
isolated the segfault and just have bad logic to fix :)
Well:
It seg faulted again :(
Here is what the log got:
[Fri Aug 29 17:45:00 2003] [notice] child pid 14541 exit signal Segmentation fault (11)
Here is a Backtrace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 14541)]
0x4052295c in modperl_wbucket_flush (wb=0x0, add_flush_bucket=0) at
modperl_filter.c:180
180 if (wb-outcnt) {
(gdb) backtrace
#0 0x4052295c in modperl_wbucket_flush (wb=0x0, add_flush_bucket=0) at
modperl_filter.c:180
#1 0x406801f2 in ?? ()
When i run gdb on the core file...
#0 0x4052295c in modperl_wbucket_flush (wb=0x0, add_flush_bucket=0) at
modperl_filter.c:180
180 if (wb-outcnt) {
(gdb) backtrace
#0 0x4052295c in modperl_wbucket_flush (wb=0x0, add_flush_bucket=0) at
modperl_filter.c:180
#1 0x406801f2 in mpxs_ap_run_sub_req (my_perl=0x8148580, r=0x81a9418) at
Apache__SubRequest.h:10
#2 0x406808da in XS_Apache__SubRequest_run (my_perl=0x8148580, cv=0x81965fc) at
SubRequest.xs:83
#3 0x405bc7ef in Perl_pp_entersub () from /usr/lib/libperl.so.5.8
#4 0x405b620a in Perl_runops_standard () from /usr/lib/libperl.so.5.8
#5 0x4055ea32 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#6 0x4055e837 in Perl_call_sv () from /usr/lib/libperl.so.5.8
#7 0x4051d6d5 in modperl_callback (my_perl=0x8148580, handler=0x80db808, p=0x815c920,
r=0x815c958, s=0x80db858, args=0x8145598)
at modperl_callback.c:53
#8 0x405231cd in modperl_run_filter (filter=0x8162938) at modperl_filter.c:400
#9 0x40523f51 in modperl_output_filter_handler (f=0x815e440,
bb=0x815e5a8) at modperl_filter.c:761
#10 0x0807e66b in ap_pass_brigade ()
#11 0x08084c15 in ap_core_translate ()
#12 0x08073b0a in ap_run_handler ()
#13 0x0807401e in ap_invoke_handler ()
#14 0x0806767f in ap_process_request ()
#15 0x080638ed in _start ()
#16 0x0815c958 in ?? ()
#17 0x0004 in ?? ()
#18 0x0815c958 in ?? ()
If you would like some more info please let me know, because I am eager
to help solve this problem.
PS -- I am running the same test scripts as I mentioned in previous
posts.
--
Craig Shelley [EMAIL PROTECTED]
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] make test failed
Alan Rafagudinov wrote: Hi! My guess is that you've been hit by this Apache problem: http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile [...] Thank you, but your advice helped with hooks/trans.t only, ok, I have added this to the troubleshooting section. filter/in_bbs_msg.t is still failed: t/TEST -v filter/in_bbs_msg.t [...] Test returned status 29 (wstat 7424, 0x1d00) [...] [Fri Aug 29 18:10:58 2003] [error] [client 127.0.0.1] File does not exist: /usr/src/httpd_perl/mod_perl-1.99_09/t/htdocs/input_filter.html that means that the filter doesn't work. Please update your cvs and show me the error_log's output when you run: t/TEST -v -trace=debug filter/in_bbs_msg Mine shows: == FILTER CALLED == FILTER READ: GET /input_filter.html HTTP/1.0 == GET line rewritten to be: GET /TestFilter__in_bbs_msg HTTP/1.0 == FILTER CALLED == FILTER READ: Host: localhost.localdomain:8536 == FILTER CALLED == FILTER READ: User-Agent: libwww-perl/5.69 == FILTER CALLED == FILTER READ: As you can see it rewrites a non-existing resource /input_filter.html to an existing one: /TestFilter__in_bbs_msg. For some reason it fails to do that for you. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Problems Installing On Debian - Or Not
Craig Shelley wrote:
Hi All,
It looked like the Debian install problems were back.
[EMAIL PROTECTED]:~/temp/modperl-2.0$ perl Makefile.PL
* WARNING *
Your Perl is configured to link against libgdbm,
but libgdbm.so was not found.
You could just symlink it to /usr/lib/libgdbm.so.1.7.3
You probably want to fix this one, at least so it won't get on the way.
* WARNING *
!!! Unable to open
/mnt/general/temp/modperl-2.0/../../home/craig/temp/mod_perl-1.99_09/ap_release.h: No
such file or directory
!!! Unable to determine server version, aborting.
!!! Please specify MP_APXS or MP_AP_PREFIX.
I thought this was a bit strange,
look at the path where it is trying to find my apache include dir.
It should be looking in /usr/include/apache2/
Anyway, I do what it says...
[EMAIL PROTECTED]:~/temp/modperl-2.0$ perl Makefile.PL MP_AP_PREFIX=/usr/include/apache2/
Reading Makefile.PL args from @ARGV
MP_AP_PREFIX = /usr/include/apache2
* WARNING *
Your Perl is configured to link against libgdbm,
but libgdbm.so was not found.
You could just symlink it to /usr/lib/libgdbm.so.1.7.3
* WARNING *
!!! invalid MP_AP_PREFIX: include/ directory not found in /usr/include/apache2
Looked at first like I would have to frig the script...
After analysing Build.pm, I noticed it was
using a load of crap data from my old installation in
/usr/local/lib/perl/5.8.0/Apache/BuildConfig.pm
So all the problems you listed above were caused by an old
Apache/BuildConfig.pm, so we are in this code in Apache/Build.pm:
if (-e lib/$bpm and (stat _)[9] $bpm_mtime) {
#reload if Makefile.PL has regenerated
unshift @INC, 'lib';
delete $INC{$bpm};
eval { require Apache::BuildConfig; };
shift @INC;
}
else {
eval { require Apache::BuildConfig; };
}
and the last eval is the one that picked the old config. I suppose we need to
prompt users before we do that. Makes sense?
After deleting this file, i had to delete what i had got from cvs, and redownload.
The second time round I ran into more problems...
[EMAIL PROTECTED]:~/temp/modperl-2.0$ perl Makefile.PL
* WARNING *
Your Perl is configured to link against libgdbm,
but libgdbm.so was not found.
You could just symlink it to /usr/lib/libgdbm.so.1.7.3
* WARNING *
!!! Unable to determine server version, aborting.
!!! Please specify MP_APXS or MP_AP_PREFIX.
Ok, so i specify the MP_AP_PREFIX option, since that was mentioned in the INSTALL file too.
I updated the install docs, to explain that MP_AP_PREFIX can be used only when
everything is installed under one tree. I will fix the INSTALL file as well.
Of course MP_APXS is the best option (since it can provide all the information
about Apache and APR), but it's still not available on win32 (Randy has a
working prototype, but one has to download it separately from Apache). And if
you haven't installed Apache yet (but built it), you can't use MP_APXS.
[EMAIL PROTECTED]:~/temp/modperl-2.0$ perl Makefile.PL MP_AP_PREFIX=/usr/include/apache2/
Reading Makefile.PL args from @ARGV
MP_AP_PREFIX = /usr/include/apache2
* WARNING *
Your Perl is configured to link against libgdbm,
but libgdbm.so was not found.
You could just symlink it to /usr/lib/libgdbm.so.1.7.3
* WARNING *
!!! invalid MP_AP_PREFIX: include/ directory not found in /usr/include/apache2
Ah that problem again...
SOLUTION:
perl Makefile.PL MP_APXS=/usr/bin/apxs2
All problems went away.
Problems occur in debian if the MP_AP_PREFIX is used because it expects a /include dir to be present.
but if the MP_APXS option is not used, the MP_AP_PREFIX is one of the tempting recommendations by the script.
The question here is, should the script have detected /usr/bin/apxs2 ?
How could possibly it do that? We shouldn't have any hardcoded paths, since if
we guess and you have more
Memory issues with DSO
I am experimenting with using mod_perl 1.2x as a DSO and have noticed that it does not share much memory between process and also seems to utilize much more memory. I thought that it is possible to use mod_perl 1.2x as a DSO when perl is compile with -Uusemymalloc and -Ubincompat5005 which it is. Is this a know issue and should building a DSO in mod_perl 1.x versions just be avoided? Thanks, Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.18-3smp, archname=i386-linux uname='linux warehouse-dev.spacdock.com 2.4.18-3smp #1 smp thu apr 18 07:27:31 edt 2002 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Ubincompat5005 -Uusemymalloc -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Uusethreads -Uuseithreads -Uuselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.3 2.96-110)', 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=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
please test a new GTop
I'm about to release a new GTop (you need it for Apache::VMonitor), please give it a try http://apache.org/~stas/GTop-0.11.tar.gz and report any problems to me (off list). Thanks. Changes since 0.10: Add support to libgtop 2.0 and automate the picking of the right libraries and include paths. [Stas Bekman] Backport GTop to perl 5.005_03 using ppport.h [Stas Bekman] __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Memory issues with DSO
Hi there, On Fri, 29 Aug 2003, Stathy G. Touloumis wrote: should building a DSO in mod_perl 1.x versions just be avoided? I think so, and so I think does Randal. This was discussed briefly here not long ago in a couple of threads, check the archives. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Memory issues with DSO
should building a DSO in mod_perl 1.x versions just be avoided? I think so, and so I think does Randal. This was discussed briefly here not long ago in a couple of threads, check the archives. Thanks, I will check the archives. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Memory issues with DSO
Sorry that I neglected to list all info : Apache version 1.3.27 mod_perl version 1.26 OS version RedHat Linux 2.4.20-18.7 perl -V : Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.4.18-3smp, archname=i386-linux uname='linux warehouse-dev.spacdock.com 2.4.18-3smp #1 smp thu apr 18 07:27:31 edt 2002 i686 unknown ' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dcccdlflags=-fPIC -Dinstallprefix=/usr -Ubincompat5005 -Uusemymalloc -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Uusethreads -Uuseithreads -Uuselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Di_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O2 -march=i386 -mcpu=i686', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.3 2.96-110)', 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=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='gcc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib' -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: where to find request object in mod_perl2
Sorry for not pointing out all details config file FilesMatch \.pl$ SetHandler perl-script PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders AddType text/html .pl Options +ExecCGI /FilesMatch my $r = Apache-request; gives Can't locate object method request via package Apache at while my $r = shift; gives an object of type 'Apache::RequestRec' Can not find how to reach header_in() from this point -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Friday, August 29, 2003 8:46 PM To: Paul G. Weiss Cc: [EMAIL PROTECTED] Subject: Re: where to find request object in mod_perl2 Paul G. Weiss wrote: The doc you reference says that Apache-request should be avoided because it is expensive. But does it in fact work? Yes. Have you actually read it? That section also explains when it's available. Igor said: this does not work under mod_perl2, without showing any error messages or explaining what kind of problem he has. On Fri, 29 Aug 2003 10:17:57 -0700, Stas Bekman [EMAIL PROTECTED] wrote: Igor Ivoilov wrote: Hello all, I have perl programs running under Apache::Registry. Now I need to switch to mod_perl2 and can not find request object. I used to get as $r = Apache-request; But this does not work under mod_perl2. http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apa che_E_gt_request_ __ 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 -- __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::DProf problems
I've installed Apache::DProf, but it seems hardly any of the calls are profiled. dprofpp shouws MOF::Dispatcher::handler as taking up 100% of the time, but there is no information recorded in for calls within that function. MOF::Dispatcher::handler is calling thousands of other functions and there is absolutely no record of any of those calls in tmon.out. Any ideas an what's going on? I'm running mp1.27 and compiled it with EVERYTHING=1 [EMAIL PROTECTED] modperl]# dprofpp logs/dprof/2734/tmon.out Total Elapsed Time = 7.359757 Seconds User+System Time = 0.349757 Seconds Exclusive Times %Time ExclSec CumulS #Calls sec/call Csec/c Name 100. 0.350 0.350 1 0.3499 0.3499 MOF::Dispatcher::handler 0.00 0.000 -0.000 1 0. - MOF::Dispatcher::ProxyCleanup::handler 0.00 0.000 -0.000 8 0. - Apache::Table::TIEHASH 0.00 0.000 -0.000 1 0. - Apache::Table::FETCH 0.00 0.000 -0.000 16 0. - Apache::Table::DESTROY 0.00 0.000 -0.000 5 0. - MOF::DBObject::DESTROY 0.00 0.000 -0.000 14 0. - DBD::Pg::db::prepare 0.00 0.000 -0.000 14 0. - DBI::st::TIEHASH 0.00 0.000 -0.000 28 0. - DBI::st::DESTROY 0.00 0.000 -0.000 14 0. - DBD::_mem::common::DESTROY 0.00 0.000 -0.000 8 0. - IO::Handle::DESTROY 0.00 0.000 -0.000 1 0. - DBD::Pg::db::quote 0.00 0.000 -0.000 7 0. - Apache::PRINT 0.00 0.000 -0.000 2 0. - Image::Magick::DESTROY 0.00 0.000 -0.000 1 0. - MOF::Object::DESTROY -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DProf problems
On Fri, 2003-08-29 at 17:11, Brian Hirt wrote: I've installed Apache::DProf, but it seems hardly any of the calls are profiled. You probably compiled that code before you initialized the debugger. Add a call to Apache::DB-init before you load your modules, as described in the Apache::DB docs. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DProf problems
Brian Hirt wrote: I've installed Apache::DProf, but it seems hardly any of the calls are profiled. dprofpp shouws MOF::Dispatcher::handler as taking up 100% of the time, but there is no information recorded in for calls within that function. MOF::Dispatcher::handler is calling thousands of other functions and there is absolutely no record of any of those calls in tmon.out. Any ideas an what's going on? I'm running mp1.27 and compiled it with EVERYTHING=1 Remember that any PerlHandler that was pulled in before Apache::DProf in the httpd.conf or startup.pl file will not have code-debugging information inserted. Make sure that you load before any code that you plan to profile. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: where to find request object in mod_perl2
Igor Ivoilov wrote: Sorry for not pointing out all details config file FilesMatch \.pl$ SetHandler perl-script PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders AddType text/html .pl Options +ExecCGI /FilesMatch my $r = Apache-request; gives Can't locate object method request via package Apache at That's much better. You need to load 'Apache::RequestUtil' Please refer to the compatibility and porting documents which give you all the info that you need: http://perl.apache.org/docs/2.0/user/porting/compat.html http://perl.apache.org/docs/2.0/user/porting/porting.html while my $r = shift; gives an object of type 'Apache::RequestRec' That's correct. Can not find how to reach header_in() from this point Again, it's in: http://perl.apache.org/docs/2.0/user/porting/compat.html __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
