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
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: 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: 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
[ANNOUNCE] Apache::IncludeHook
hi all... I wanted to let everyone know that I have ported 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 AddType text/html .shtml AddOutputFilter INCLUDES .shtml Options +Includes 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 here 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 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 E[EMAIL PROTECTED] 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: [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
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
Steve Hay wrote: > 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. Your patch passes the current interpreter context to modperl_hash_seed_init(), and thus the interpreter-wide variables. I don't see problems with it, but I don't know anything about the mod_perl 2 internals. I've a minor comment : > @@ -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(), When possible, try to use Perl_error_log instead of PerlIO_stderr(). It's equivalent to it, but checks for the availability of STDERR beforehand. And BTW the trace below should probably be out#defined for non-debug builds. > + "\nmod_perl: using init hash seed: %"UVuf"\n", > MP_init_hash_seed); > } > } > @@ -587,10 +588,12 @@
Re: Apache::Session permissions problem
On Fri, 12 Sep 2003 01:01:24 -0600 Eric Schwartz <[EMAIL PROTECTED]> wrote: Hi Eric, > I found a pretty useful article at > http://www.linuxjournal.com/article.php?sid=4143 on how to use > Apache::Session with Mason. I wrote a tutorial on session management with HTML::Mason and Apache::SessionManager (a wrapper around Apache::Session) available at: http://search.cpan.org/author/ENRYS/Apache-SessionManager-0.06/SessionManager/cookpod.pod#Apache::SessionManager_WITH_HTML::Mason I hope that it will be useful for you. Yes, I know, now there is a Mason extension to handle sessions (not in the Mason core), _but_: 1) when I wrote Apache::SessionManager, the extension wasn't yet available :-) (moreover A::SM has a session expiration/inactivity built-in cleanup mechanism) 2) with Apache::SessionManager you can use session object also in other Apache life request phases than Response phase (for example I need session in Authentication phase). With MasonX::Request::WithApacheSession you cannot (if I not mistake) 3) There is no way to use URI session tracking (session id is embedded in left side of the URI) In all other case, MasonX::Request::WithApacheSession works fine. by - Enrico
[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 -I"C:\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: 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
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Stas Bekman wrote: Steve Hay wrote: Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) what is mod_perl.lib? a static library? (I guess an equivalent of mod_perl.lo on unix). We don't install it on unix yet, but I think that for consistency it should go to the same place where mod_perl.so is installed to. Which is under the Apache tree. This mod_perl.lib (on Win32) isn't a true static library, containing all the symbol definitions; from what I understand, it just contains the minimal information on symbols needed to allow the application it's being linked with to find the symbols in the dynamic library (in this case, mod_perl.so). I put it under Apache2/lib/ because that's where the Apache2 libs (eg, apr.lib, libapr.lib, mod_dav.lib) are placed. The dynamic libraries are placed either under Apache2/modules/, if it's a module (eg, mod_dav.so), or under Apache2/bin/, such as libapr.dll. Ah, so it's all cool. I have confused Apache2/ with perl's lib sub-directory. Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' => 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? Nope, it uses this attribute as a source dir in cp from to: $install .= <<'EOI'; # install mod_perl.lib @$(MKPATH) $(MODPERL_AP_LIBDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_LOCATION) && \ $(MODPERL_CP) $(MODPERL_LIB_LOCATION) $(MODPERL_AP_LIBDIR) EOI And as you can see it should install the static lib under $(MODPERL_AP_LIBDIR) (which is under the apache tree) purhaps it should be fixed to have a more intuitive name then (s/MODPERL_LIB_LOCATION/MODPERL_LIB_SOURCE_LOCATION/?) or BUILD_LOCATION I'd suggest an even more intuitive: MODPERL_STATIC_LIB_BUILD_LOCATION, since it's a static lib. Purhaps adding a new var MODPERL_STATIC_LIB_LOCATION pointing to where the static lib was installed to will be useful. Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. I'm not sure that's the *only* mis-leading part, but, as you say, if it all works then it shouldn't really matter too much. The main thing is to get mod_perl.lib installed in the first place under mp1. - Steve