Re: AIX perfomance
On Fri, Sep 12, 2003 at 04:12:00PM +0100, Ged Haywood wrote: Hi there, On Fri, 12 Sep 2003, William McCabe wrote: I've got a lot of experience with mod_perl on both linux and AIX and can state categorically that there are no typical conditions which would cause AIX run strangely slowly compared to linux on comparable hardware. That's useful information, thanks Bill. We don't see much about AIX here but it seems to me that it's been becoming more common recently. AIX will of course have an massive growth in popularity now that SCO has withdrwan IBMs un*x licence. ;* Paddy
[PATCH] Re: mp2 with perl-5.8.1 on Windows
Randy Kobes wrote:
On Fri, 12 Sep 2003, Steve Hay wrote:
Hi,
Has anybody else got mp2 (CVS) working with recent perl-5.8.1's on Windows?
I've got it building, but I can't start the Apache server at all. (It's
fine without the mod_perl bits in the httpd.conf file.)
See this thread on p5p for what I'm getting:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg00795.html
Cheers,
- Steve
I also found a problem, as below:
==
Perl_safesysmalloc(unsigned int 0x0010) line 70 + 21 bytes
: perl-5.8.1/util.c
modperl_hash_seed_init(apr_pool_t * 0x0026a7f0) line 44 + 7 bytes
: modperl-2.0/src/modules/perl/mod_perl.c
modperl_hook_pre_config(apr_pool_t * 0x0026a7f0,
apr_pool_t * 0x00848100, apr_pool_t * 0x0084a108) line 594 + 9 bytes
: modperl-2.0/src/modules/perl/mod_perl.c
ap_run_pre_config(apr_pool_t * 0x00401441, apr_pool_t * 0x0026a7f0,
apr_pool_t * 0x00848100) line 126 + 49 bytes
main(int 0x00401d82, const char * const * 0x0008) line 575 + 19 bytes
APACHE! mainCRTStartup + 227 bytes
==
which seems to be related to the safemalloc() call on line
44 of src/modules/perl/mod_perl.c. (by the way, I had to
comment out the fprintf() call at line 66 to get it to
compile, otherwise an error about my_perl being undeclared
was found).
I still haven't found out what the problem with the server crashing on
startup is, but the attached patch against CVS seems to fix the
fprintf() problem that you refer to.
I've no idea how advisable what I've done is, but without it I get:
=
cl -IC:/Temp/modperl-2.0/src/modules/perl
-IC:/Temp/modperl-2.0/xs -IC:\
apache2/include -IC:\apache2/include -nologo -Gf -W3 -Od -MD -Zi
-DDEBUGGING -DW
IN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT
-DPERL_IM
PLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -IC:\perl\lib\CORE
-DMOD_PERL -
DMP_COMPAT_1X -Od -MD -Zi -DDEBUGGING -c mod_perl.c
C:\perl\bin\perl.exe -M
ExtUtils::Command -e mv mod_perl.obj mod_perl.lo
mod_perl.c
mod_perl.c(66) : error C2065: 'my_perl' : undeclared identifier
mod_perl.c(66) : warning C4047: 'function' : 'struct interpreter *'
differs in l
evels of indirection from 'int '
mod_perl.c(66) : warning C4024: 'Perl_IStdIO_ptr' : different types for
formal a
nd actual parameter 1
mod_perl.c(66) : warning C4047: 'function' : 'struct interpreter *'
differs in l
evels of indirection from 'int '
mod_perl.c(66) : warning C4024: 'Perl_IStdIO_ptr' : different types for
formal a
nd actual parameter 1
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
=
and with it, it all builds OK.
- Steve
PS. Randy: How do you that stacktrace output that you've posted? Is
that using MSVC++, or something else?
--- mod_perl.c.orig 2003-09-11 19:10:39.0 +0100
+++ mod_perl.c 2003-09-15 12:00:30.273019100 +0100
@@ -22,7 +22,7 @@
#endif
/* see modperl_hash_seed_set() */
-static void modperl_hash_seed_init(apr_pool_t *p)
+static void modperl_hash_seed_init(pTHX_ apr_pool_t *p)
{
#ifdef MP_NEED_HASH_SEED_FIXUP
char *s;
@@ -63,7 +63,8 @@
if (s) {
int i = atoi(s);
if (i == 1) {
-fprintf(stderr, \nmod_perl: using init hash seed: %UVuf\n,
+PerlIO_printf(PerlIO_stderr(),
+ \nmod_perl: using init hash seed: %UVuf\n,
MP_init_hash_seed);
}
}
@@ -587,10 +588,12 @@
int modperl_hook_pre_config(apr_pool_t *p, apr_pool_t *plog,
apr_pool_t *ptemp)
{
+dTHX;
+
/* we can't have PerlPreConfigHandler without first configuring mod_perl */
/* perl 5.8.1+ */
-modperl_hash_seed_init(p);
+modperl_hash_seed_init(aTHX_ p);
return OK;
}
Re: [PATCH] Re: mp2 with perl-5.8.1 on Windows
On Mon, 15 Sep 2003, Steve Hay wrote: PS. Randy: How do you that stacktrace output that you've posted? Is that using MSVC++, or something else? Hi Steve, I'm using MSVC++ ... When a problem like this occurs, an offer is made to call up the VC++ debugger, where the trace is then done. In order to get a more useful trace (with symbol information), I compiled Perl using some patches to perl-5.8.x/win32/Makefile that ActiveState introduced (http://aspn.activestate.com/ASPN/Downloads/ActivePerl/Source). This patch enables debug symbols in release builds, and involves using '-Zi' in $(OPTIMIZE) and '-debug -opt:ref,icf' for $(LINK_DBG). With this, one gets .pdb files corresponding to compiled libraries, which hold the symbol information (I had to manually copy perl58.pdb [corresponding to perl58.dll] to C:\Perl\bin). The Apache/2.0.47 sources have this also enabled for the release build, by default, and building mod_perl as 'perl Makefile.PL ... MP_DEBUG=1' will enable them in mod_perl as well. -- best regards, randy
Re: [PATCH] Re: mp2 with perl-5.8.1 on Windows
Randy Kobes wrote: On Mon, 15 Sep 2003, Steve Hay wrote: PS. Randy: How do you that stacktrace output that you've posted? Is that using MSVC++, or something else? Hi Steve, I'm using MSVC++ ... When a problem like this occurs, an offer is made to call up the VC++ debugger, where the trace is then done. In order to get a more useful trace (with symbol information), I compiled Perl using some patches to perl-5.8.x/win32/Makefile that ActiveState introduced (http://aspn.activestate.com/ASPN/Downloads/ActivePerl/Source). This patch enables debug symbols in release builds, and involves using '-Zi' in $(OPTIMIZE) and '-debug -opt:ref,icf' for $(LINK_DBG). With this, one gets .pdb files corresponding to compiled libraries, which hold the symbol information (I had to manually copy perl58.pdb [corresponding to perl58.dll] to C:\Perl\bin). The Apache/2.0.47 sources have this also enabled for the release build, by default, and building mod_perl as 'perl Makefile.PL ... MP_DEBUG=1' will enable them in mod_perl as well. Sorry, I should have made my question more specific. I've actually rebuilt Perl and Apache as full debug builds so I have all these .pdb files already. mod_perl gets them too because it inherits Perl's debug build mode. My question was where in the DevStudio GUI do you get at the stacktrace that you posted, or how do you get DevStudio to dump it out for you? All I can find is a Context drop-down (in the panel showing variables' values) from which I have to manually copy down the information (hence I only posted a list of functions!) It doesn't look like you've done that! - Steve
[ANNOUNCE] Apache::IncludeHook
hi all...
I wanted to let everyone know that I have ported !-- #perl -- SSI tag
support to Apache 2.0. it should behave under both prefork and threaded
mpms, and work pretty much the same as it did in Apache 1.3, despite the
fact that mod_include is now an output filter.
while the support is fairly complete, the code is a bit messy and can be
refactored. however, I wanted to get something released for people to play
with before I needed to move on to something else.
--Geoff
The URL
http://www.modperlcookbook.org/~geoff/modules/Apache-IncludeHook-2.00_01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GE/GEOFF/Apache-IncludeHook-2.00_01.tar.gz
size: 7289 bytes
md5: 0753eda141bf886290fa872fbffaf580
from the README:
NAME
Apache::IncludeHook - #perl Server Side Include support
SYNOPSIS
PerlModule Apache::IncludeHook
Alias /ssi /usr/local/apache/htdocs
Location /ssi
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
Options +Includes
/Location
DESCRIPTION
Apache::IncludeHook offers support for #perl tags in
documents parsed by the mod_include engine included in
the Apache 2.0 distribution. Supported formats include
!--#perl sub=My::PrintArgs --
!--#perl arg=fee sub=My::PrintArgs arg=fie --
!--#perl arg=foe sub=My::PrintArgs::handler --
!--#perl arg=fum sub=My::PrintArgs-method_handler -- here
!--#perl arg=I smell sub=sub { my $r = shift; print @_ } --
In Apache 1.3, mod_include supported #perl tags out of
the box. In 2.0, support for tags outside the standard
mod_include realm ('echo', 'flastmod', etc) have been removed,
having been replaced with an API that allows you to hook
your own functionality into mod_include's parsing engine.
The 'exec' tag is an example of one that is no longer natively
supported by mod_include - mod_cgi now supplies the base
implementaiton of this tag.
The current hope with this module is simply to carry over #perl tag
support from Apache 1.3 to 2.0. Apache::SSI-like support
for custom tags will (possibly come later). keep in mind
that while this module is not inteneded to replace the old
Apache::SSI for Apache 1.3, because the new Apache 2.0 API
includes a filtering mechansim,
you already have the ability to post-process SSI tags via
Perl (or C) output filters.
EXAMPLE
file.shtml:
perl !--#perl arg=one sub=My::PrintArgs -- here
PrintArgs.pm:
package My::PrintArgs;
use Apache::RequestRec ();
use Apache::Const -compile = 'OK';
use strict;
sub handler {
my ($r, @args) = @_;
print join ' ', '***', (join ' : ', @args), '***';
return Apache::OK;
}
which is almost identical to what you would see with mod_perl 1.0,
save the mod_perl 2.0 specific classes.
NOTES
This implementation is designed to hook into the mod_include
that ships with Apache 2.0. It will not work with Apache 2.1.
This is alpha ware, subject to massive API changes. Meaning,
the TIEHANDLE interface may go away and you may be forced to
use only the (currently non-existent) filter interface. so
get to know filters now before it's too late (they're really
cool anyway).
FEATURES/BUGS
Subrequests are still a work in progress - they still don't seem
to work properly from filters.
only print STDOUT and $r-print are supported. other methods
of sending content to the client still need to be implemented.
AUTHOR
Geoffrey Young Elt[EMAIL PROTECTED]gt
COPYRIGHT
Copyright (c) 2003, Geoffrey Young
All rights reserved.
This module is free software. It may be used, redistributed
and/or modified under the same terms as Perl itself.
Re: mod_perl v2 Forking
Cameron, Have you tried issuing the command to `at`? If you don't need to interact wih the report generator, and can pass all the parameters in the command line or via a tmp file, this is a great solution. at (and the corresponding atd) will preserve your environment vars and other niceties. regards, martin
Re: Apache::Session permissions problem
On Saturday, Sep 13, 2003, at 09:22 America/Denver, Perrin Harkins wrote: I found a pretty useful article at http://www.linuxjournal.com/article.php?sid=4143 on how to use Apache::Session with Mason. I'm afraid that is not a very good article. It's out of date, and shows poor error handling. If you want to use sessions with Mason, you should be using the session handler that Mason provides. That is available on CPAN and is supported on the Mason list. Beggars can't be choosers, and all that, but would you mind telling me what handler you're talking about? I looked around for session handling and Mason, and that article was the best one I found in terms of explaining how it worked and how to use it. Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. How can I know this? The documentation for Apache::Session::DBIStore (which A::S::DBI refers to) doesn't say anything about being obsolete or deprecated. Is there an archive of received wisdom somewhere I should be checking to validate articles like the one I found? You shouldn't use the IPC locking in Apache::Session. You didn't mention which database you're using, but most of them have alternative ways of doing locking. In my opinion, the locking approach taken in Apache::Session is not a good one for the average web site and you should simply turn it off by using the NullLocker. How? I never asked for IPC locking; it somehow snuck in. It's not particularly obvious from the documentation I can find that it's going to be used, or how to select alternative methods. I installed Apache::Session from CPAN, and the docs refer to PosixFileLocker SysVSemaphoreLocker and NullLocker, but no perldocs for those modules are on my system. I'm honestly trying to figure out how I can draw those conclusions for myself, so I'm not stuck asking this list about them. Suggestions are more than welcome; I'm not quite sure how Session::SysVSempaphoreLocker got involved in the first place, since I don't explicitly reference it. Apache::Session::DBI uses it for locking. 'perldoc Apache::Session::DBI' says it uses A::S::PosixFileLocker, not A::S::SysVSemaphoreLocker. Are the docs wrong, or the code? -=Eric
Re: Apache::Session permissions problem
Eric, Sorry if I came off overly critical. Many people have had problems trying to use Mason with Apache::Session because of that article. This is why on the Mason website the link to that article describes it as outdated and steers people to newer documentation. (It probably should also steer them to the new handler...) Eric Schwartz wrote: Beggars can't be choosers, and all that, but would you mind telling me what handler you're talking about? I looked around for session handling and Mason, and that article was the best one I found in terms of explaining how it worked and how to use it. Did you look on the Mason site, http://masonhq.com/? That's the best place to find information on Mason. A search for session on that site includes a reference to MasonX::Request::WithApacheSession, available from CPAN. This is mentioned in the administrator's manual that comes with Mason. It's possible that you have an old version of Mason that predates this. Apache::Session::DBI (which is what the article refers to) is ancient and should not be used. How can I know this? The documentation for Apache::Session::DBIStore (which A::S::DBI refers to) doesn't say anything about being obsolete or deprecated. Is there an archive of received wisdom somewhere I should be checking to validate articles like the one I found? The latest Apache::Session on CPAN is version 1.54, released in October 2001. The last release that included a module called Apache::Session::DBI was version 1.03, released two years earlier. I'm not certain what CPAN.pm would do if you told it to install Apache::Session::DBI. It might install the old one, which would be very unfortunate. Is that how you installed it? You shouldn't use the IPC locking in Apache::Session. You didn't mention which database you're using, but most of them have alternative ways of doing locking. In my opinion, the locking approach taken in Apache::Session is not a good one for the average web site and you should simply turn it off by using the NullLocker. How? By using Apache::Session::Flex. The configuration for MasonX::Request::WithApacheSession also lets you do this. It's not particularly obvious from the documentation I can find that it's going to be used, or how to select alternative methods. Look at the source and you'll see it. It's all much clearer in the more recent release though. I installed Apache::Session from CPAN, and the docs refer to PosixFileLocker SysVSemaphoreLocker and NullLocker, but no perldocs for those modules are on my system. The Apache::Session::PosixFileLocker and Apache::Session::SysVSemaphoreLocker modules are included with Apache::Session (although both are obsolete and only part of the old version that you installed). They have no documentation, so perldoc will not find them. The later equivalents (Apache::Session::Lock::File) do have docs. 'perldoc Apache::Session::DBI' says it uses A::S::PosixFileLocker, not A::S::SysVSemaphoreLocker. Are the docs wrong, or the code? The docs are wrong. You can see it refers to the semaphore locker if you look at the source. Basically, you stumbled across an old article that referred to an obsolete version of Apache::Session, and all of your problems stem from that. If you get a later version and check out the Mason handler and the newer documentation on masonhq.com, I think it will all start to make sense to you. - Perrin
Re: [PATCH] Re: mp2 with perl-5.8.1 on Windows
On Mon, 15 Sep 2003, Steve Hay wrote: I've actually rebuilt Perl and Apache as full debug builds so I have all these .pdb files already. mod_perl gets them too because it inherits Perl's debug build mode. My question was where in the DevStudio GUI do you get at the stacktrace that you posted, or how do you get DevStudio to dump it out for you? All I can find is a Context drop-down (in the panel showing variables' values) from which I have to manually copy down the information (hence I only posted a list of functions!) It doesn't look like you've done that! Hi Steve, I see now; that's something I struggled with too, until Doug pointed this out; try Alt+7 to give a stacktrace window (look under View - Debug Windows). And perhaps also to save some grief, if you want to copy it, select+right-click within that window doesn't work; you have to select+Edit-Copy. -- best regards, randy
