Re: Can you have mod_perl 1.26 with Apache 2.0.39?
Grant Cooper wrote: Can you have mod_perl 1.26 with Apache 2.0.39? I was unable to to install mod_perl from ports but was able to do a pkg_install mod_perl 1.26. Seems to work now but now I have apache version 1.3.22 where I use to have 2.0.39. Is this because mod_perl 2.0 is meant for apache 2 and is not compatible with 1.3.22? I can't find any compatibility documentation. No, you cannot mix these, see: http://perl.apache.org/docs/2.0/user/help/help.html#Wrong_Apache_mod_perl_combination Whenever you have a problem, remember to peruse the shortcuts menu on the left side of all pages at perl.apache.org and one of the two entries should save you (and us) a lot of time: Report 1.0 Problems Report 2.0 Problems __ 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
Re: $r-dir_config-(un)set issue...
simran wrote: Does that mean that $r-dir_config is not the same as $r-server-dir_config ? not the same, $r-dir_config is a merge of the Location section setting with Server/Vhost settings, $r-server-dir_config is only for Server/Vhost settings. __ 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
Re: while - modperl 2.0/Apache 2.0
Udlei Nattis wrote: hi, this problem is stranger when i use apache 1.3/modperl 1.27 this problem don't exist i think problem is because thread in apache2 or modperl2 That's the thing. I've had the same behavior with apache 1.3/modperl 1.27, so I don't think this has anything to do with Apache or mod_perl. (This is on linux) lynx dont have problem because is other instance if you open 2 instances of mozilla you dont have problem but if you open one mozilla and 5 tab navigator of instance problem persist []s nattis Stas Bekman wrote: Stas Bekman wrote: Alessandro Forghieri wrote: Greetings. I have observed the same behavior (on win32). Scripts that are invoked from the same browser through the same URL appear to bind to the same perl thread and are therefore serialized. Changing the URL appears to bind the request to a different thread. (My observation regarded access from a different Location: Udei's experience shows that a URL change suffices). I have often wondered wether this is incidental or specified behaviour. OK, I've returned to this problem. And the bug is in Apache 2.0 not mod_perl. I was able to reproduce the serialization problem with a plain cgi-bin script. Will report to the httpd-dev list and hopefully it'll be resolved in the future version. I'm taking my words back. I did some more testing and the same problem can be reproduced with Apache 1.3. So I have tried different browsers and chased the problem to be a browser's fault. Here is the status on linux: Opera, Mozilla, Galeon - serialize the requests to the same URL. Konqueror, lynx- run both in parallel. Luckily I didn't sent the bogus bug report to httpd-dev ;) __ 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
Re: Warnings clarification
William McKee wrote: Hi, I've been using Perl for several years to develop simple CGI applications for my clients. I'm now in the process of migrating to mod_perl for the performance benefit it gives. In so doing, I've been lurking on this list and reading the Guide. Presently, I'm trying to debug a problem with a segmentation fault in the Petal module that Jean-Michel Hiver announced a couple weeks ago on this list. As I was reading the guide, The Importance of Warnings section in the Debugging chapter, suggested setting PerlWarn On on the development machine. My question is whether this setting is the same as the -w switch and the 'use warning' pragmas. I suspect it is, but the guide did not clarify this point. Have you read this? http://perl.apache.org/docs/1.0/guide/porting.html#Warnings If yes, what part you are still confused about? I think the definitions are very clear. -- __ 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
Re: Warnings clarification
William McKee wrote: On 31 Jul 2002 at 20:56, Stas Bekman wrote: Have you read this? http://perl.apache.org/docs/1.0/guide/porting.html#Warnings No, I was reading this-- http://perl.apache.org/docs/1.0/guide/debug.html#The_Importance_of_Warnings The information in the link you posted is I was seeking. Perhaps a cross-reference would be useful. I just added it. __ 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
ANNOUNCE: Debug::SIGSEGVTrace
() $trace-ready(); This method sets the SIGSEGV sighandler. Only after this method is called the extract of the trace will be attempted on the event of SegFault. Notice that it sets the handler to be called only once. If another segfault happens during the processing of the handler, the SIGSEGV handler that was previously set will get invoked. If none was previously set the default SIGSEGV handler will attempt to dump the core file if the environment is configured to allow one (via shell's limit command and possibly other system-dependent manipulations). RELATED NOTES When you want to get a useful backtrace the debugger must be able to resolve symbols. Therefore the object in question must have its symbols preserved and not stripped. This is usually accomplished by compiling the C code with -g. Since this code gets called from Perl, which in turn may be embedded into some other application (e.g., mod_perl enabled Apache), you probably want to have *libperl.so* and the application it's embedded to, to be compiled with the debug symbols non-stripped. For example to build a Perl package which includes XS/C objects, add: WriteMakefile( ... DEFINE= '-g', ... ); To build Perl in debug mode: ./Configure ... -Doptimize='-g' ... To build Apache 1.3 without stripping the symbols: ./configure ... --without-execstrip To build Apache 2.0 in the debug mode: ./configure ... --enable-maintainer-mode ... BUGS * When you run the handler you might get things like: /tmp/Debug-SIGSEGVTrace-0.01/24043: No such file or directory. This is a bug in older versions of gdb, simply ignore it. * It probably won't compile on Win32. If you know how please submit patches. EXPORT None. TODO * the code is not thread-safe (so it's not running under mod_perl 2.0 with worker mpm :(. The question is how to pass data to the SIGSEGV signal handler, without using static variables. * clean the backtrace from extra frames added by this module * how do we pass the test suite if we exit(2)? currently used fork() to workaround it, but it's not very portable. * how do we clean-up the autogenerated gdb-command file if we exit(2)? * support other debuggers than gdb. Need your input/patches. Currently this module works only on systems with gdb installed. I'm not sure how portable is my C code, but should probable work on any POSIX-complient system. If you know how to make the code more portable, or support other debuggers on other OSes please send patches. ACKNOWLEDGEMENTS The idea has been borrowed from the GNOME's gnome-crash project, which is used to automatically extract a backtrace when reporting a bug. Parts of the C non-blocking-read implementation were borrowed from Matt Sergeant's PPerl project. AUTHOR Stas Bekman [EMAIL PROTECTED] SEE ALSO perl(3), Debug::SIGSEGVFault(3). __ 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
a new doc: Preparing mod_perl modules for CPAN
I've just added a new doc: Preparing mod_perl modules for CPAN http://perl.apache.org/docs/general/cpan_mod_dev/cpan_mod_dev.html If you have useful input please send it to me. __ 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
Re: get_remote_host for mod_perl2
Tim Keefer wrote: Hi All, Any ideas for retrieving the users ip address within a mod_perl2 module? mod_perl1 has $r-get_remote_host. Is their something similar in mod_perl2? I've searched all the mod_perl2 docs on perl.apache.org and couldn't find anything about this. in 2.0 it's: use Apache::Connection; $r-connection-remote_host(); I'm not sure why Doug renamed it, but I just committed a patch to the compat layer. will update the doc too. p.s. Lyle is working on automatic docs extraction from httpd header files. once this is done the 2.0 API will appear online. Currently use search t/ for API usage. __ 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
Re: Fwd: Re: Apache::DBI as a prerequisite
Simon Perrault wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On July 30, 2002 10:02 pm, Stas Bekman wrote: 2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html Though you can really rely on it once Apache::Test is released, which will happen when mod_perl 2.0 is released. 1) That's an interesting problem. It seems that nobody has asked this question before. Here is my take on it. If you like this solution I'll add it to the docs. Thanks a lot. Your solution for Apache::DBI works and is very Perlish! Great. I've put it here: http://perl.apache.org/docs/general/cpan_mod_dev/cpan_mod_dev.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
Re: Mandrake defalut mod_perl dose not seem to be working.
Roy Souther wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 31 July 2002 08:40 pm, Stas Bekman wrote: What do you mean by doesn't work? Try: http://perl.apache.org/docs/1.0/guide/install.html#How_can_I_tell_whether_m od_perl_is_running_ The two tests they recommend give conflicting results. The log file says that mod_perl was started. The command line test httpd -l says it is not compiled in. The problem here is that mod_perl and apache doc recommend that you disable httpd and run httpd_modperl in it's place but Mandrake runs both httpd and httpd-perl that is the binary they ship with mod_perl. They must have renamed it. They both of them and each has it's own set of configuration files. So I did wget -S 127.0.0.1 and the mod_perl does not show there. So I can not confirm that mod_perl is running or not. I use Mandrake but I never use apache/mod_perl rpms but build my own, so I don't know. But it seems that you test the wrong binary 'httpd -l', if error_log says that you are running mod_perl you are running mod_perl. Is there a simple test file I could use to see if it is running? Or some other test I could do? Configure a registry section http://perl.apache.org/docs/1.0/guide/getwet.html#Configuring_and_Starting_the_mod_perl_Server and run a simple script: http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_a_CGI_script -- __ 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
Re: Apache::Status bugfix ( :: doesn't play well in filenames)
thanks, but how about sending a patch using diff?
http://perl.apache.org/contribute/cvs_howto.html#Sending_Patches
sub noh_b_graph {
my $r = shift;
require B::Graph;
untie *STDOUT;
my $dir = $r-server_root_relative(
$r-dir_config(GraphDir) || logs/b_graphs);
mkdir $dir, 0755 unless -d $dir;
(my $thing = $r-path_info) =~ s:^/::;
$thing =~ s{::}{-}g; # cause some OS's dont' allow :: in filenames
## the line above you should add
## the line before it is # 516
__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.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
Re: T switch is ignored modperl2.0
Kent, Mr. John wrote:
Greetings,
I have put PerlSwitches -T in my httpd.conf file, yet keep getting the
following warning
in the server's error_log:
[Tue Jul 23 10:43:06 2002] [warn] T switch is ignored, enable with
'PerlSwitches -T' in httpd.conf
Any suggestions?
the cvs version or the next release won't complain anymore. currently -T
on shebang line is simply ignored, but will complain again in the future
when we will have a flag indicating whether the taint mode is on or not.
in perl 5.8.0 it's easy:
% perl5.8.0 -Te 'print ${^TAINT}'
in older Perls one need to parse PerlSwitches to find -T and set some
magic flag (was $Apache::__T in mod_perl 1.0).
__
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
Re: hiding perl code
Michael Robinton wrote: see attached [...] BZS::License performs a similar load operation to BZS::Loader. First, however it looks for a hash pointer in the caller program called $ptr2_License. The hash contains the path to the License file and an optional 'private' key list of modules which will decrypt only with the 'private' key. BOR, a I thought that somebody has already said here that you cannot hide your perl code. if you have an access to the perl interpreter you can dump the source code after it was decrypted. wouldn't it be a good idea to add the truth to the POD so not to mislead the crowd? I've read through the doc but didn't see a word mentioning this little caveat. Shouldn't the module be renamed to BZS::Obscure::...? ;) __ 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
Re: Mention LoadFile in the mp2 docs?
Alessandro Forghieri wrote: Greetings. From: http://perl.apache.org/docs/2.0/user/config/config.html#Enabling_mod_perl [...] Win32 users need to make sure that the path to the Perl binary (e.g., C:\Perl\bin) is in the PATH environment variable. [...] Is it not true that the directive LoadFile C:\foo\perl58.dll makes path modifications unnecessary? I guess the generic doc should simply redirect win32 users to http://perl.apache.org/docs/2.0/os/win32/config.html and not bother providing incomplete info. But I don't see that doc mentioning this issue. Randy? If so, it should perhaps be mentioned here. (With caveats, as situations where Registry scripts are handled by one - LoadFil-ed - perl version and CGI scriptse by another one - or not at all - would probably be confusing...). Cheers, alf -- __ 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
Re: Win32: Apache2+modperl2 STDERR not going to error.log?
Alessandro Forghieri wrote: Greetings. I am using the binary distribution Apache/2.0.40-dev (Win32) mod_perl/1.99_05-dev Perl/v5.8.0 from uwinnipeg. OS is NTsp6 httpd.conf is basically unmodified. I have noticed that carp'ing or warn'ing or even printing to stderr from a Registry script does not send anything to error.log. The same from CGI does produce the expected log records - verified on printenv. Also I am under the impression that the same does *NOT* happen on Win2K, but I cannot confirm it right now. Is this a known issue with this version, a by-design thing, or is it just me? FWIW, there are no problems on linux. Do you have the same problem with v5.6.1? Meanwhile try using the logging methods if possible: http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Log.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
Re: Apache::Reload - filtering include directories
[...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ 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
Re: Segmentation fault
Vitor wrote: Hello Folks, I am having a big problem here. While i try to open a new Mail::CClient connection, i get these message : [Fri Jul 19 17:56:28 2002] [notice] child pid 6146 exit signal Segmentation fault (11) I am using Perl 5.6.1, Apache/1.3.23 , PHP/4.1.1 mod_perl/1.26, without shared libraries, and HTML::Mason templating system. I don't know if is a callback problem, because to login, Mail::CClient uses a login callback. It works well as a cgi, but under mod_perl/Mason, i get those message. You need to send a backtrace and other info as explained at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems and probably post it to the mason list and not here if this happens only under mason. __ 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
Re: apache mod_perl + suid question
[EMAIL PROTECTED] wrote: Hello, I am trying to write a password changing program. this article by Lincoln Stein should resolve most of your problems: http://www.samag.com/documents/s=1286/sam03020006/ and no, don't try to disable the taint mode, instead read the perlsec manpage to learn how to make your program run under -T. -- __ 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
Re: Apache2 CWD Non-threaded MPM
Joshua Bernstein wrote: Hey All, After much hassle, I blew away my threaded MPM under Apache2 because mod_perl didn't seem to be accepting or processing the . (period) in my @INC path so that scripts called like: require blah.cgi were not being found in the include path. I understand there are still issues with SafeCWD'ing in a threading enviroment, but now that the MPM is prefork, it isn't threaded anymore. Any reason why mod_perl 2, still doesn't recognize the . in my @INC path? You are talking about ModPerl::Registry, not mod_perl 2.0 in general. ModPerl::Registry will always do the same thing, be it the prefork mpm or the threaded mpm. Because the same code should run identically no matter what the mpm is used. Therefore if chdir() cannot be used with the threaded mpm it won't work with the prefork mpm as well. Solution 1: Subclass ModPerl::Registry as ModPerl::RegistryPreFork and do whatever is fine with prefork. Subclassing the new registry family is extremely easy, though the API hasn't been frozen yet. See ModPerl::RegistryCooker for more info. Solution 2: Arthur Bergman is working on ex::threads::safecwd, which should resolve the problem for threaded mpms. So once it's available we can use chdir() in ModPerl::Registry again. __ 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
Re: apache/mod_perl help
Dinesh Patel wrote: I'm trying upgrade my mod_perl version from 1.27 to 1.99.02 for apache-2.0.39. version 1.27 of mod_perl was compiled using : CC=cc OPTIM=-O $INET_TOP/bin/$OPSYS/perl Makefile.PL \ DO_HTTPD=1 PERL_AUTHEN=1 PERL_SECTIONS=1 make The question is how do I compile 1.99.02 with the PERL_AUTHEN and PERL_SELCTIONS enabled! It's too early to upgrade to mod_perl 2.0. Not all features are implemented (which is the case with Perl sections). For more info see: http://perl.apache.org/docs/2.0/user/index.html I have compiled the new version of mod_perl without the PERL values, The httpd.conf was edited to include : # mod_perl stuff Alias /cgi-bin/ /INDATA/inet_data/httpd/cgi-bin/ Location /cgi-bin SetHandler perl-script PerlHandler Apache::Registry PerlSetupEnv On Options ExecCGI /Location PerlWarn On PerlScript /INDATA/inet_data/httpd/cgi-bin/startup.pl however when i try and start the apache server i get the error : Syntax error on line 1067 of /INDATA/inet_data/httpd/conf/httpd.conf: Invalid command 'PerlSetEnv', perhaps mis-spelled or defined by a module not included in the server configuration Any help would be appreciated Regards Dinesh Patel -- __ 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
Re: Apache::Reload - filtering include directories
Harry Danilevsky wrote: Two reasons : 1. My site-specific modules don't necessarily have a common namespace (or even several namespaces); they just all live in /site/lib. Without a ReloadDirectories-like filter every time I add another module, say, /site/lib/Reports.pm I'll need to add Reports to ReloadModules, and restart the server. That's the thing. It's a good idea to alway use some prefix package name in all your modules, to avoid future clashes with other modules. And it automatically solves your problem with Apache::Reload. 2. Much more obscure, related to HTML::Mason. As I mentioned in my post: In Mason components are precompiled and cached, so that perl code doesn't have to be re-parsed for every request. The cached files are require(d), and they end up in %INC. It appears from ReloadDebug's output that those cached files are being checked by Apache::Reload, and if they have been modified - they'll be reloaded. The problem is, if the code has a syntax error, that error will occur when Apache::Reload re-require()s that file, and the error message will be printed to a log file, not to the browser - which is what Mason would do. So your browser will simply tell you that 'Internal error has occurred' ReloadDirectories will simply ignore them, and let Mason deal with modified files. If you tell Apache::Reload to look only at certain namespaces, this problem doesn't exist anymore. Am I still missing something ? Harry Danilevsky [EMAIL PROTECTED] Stas Bekman wrote: [...] Anyway, I decided to add another directive to Apache::Reload PerlSetVar ReloadDirectories /site/lib /usr/local/apache/conf Apache::Reload allows you to define which modules to reload using the patterns like so: PerlSetVar ReloadAll Off PerlSetVar ReloadModules Apache::* My::* Is there any reason why you cannot use this approach? I've no objection to your proposal, just wondering whether the existing features can be used instead. __ 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
Re: I can see Apache.pm, why can't he?
Dennis Daupert wrote: What's up with this? I'm trying to load Apache::DBI on startup. I have apache and mod_perl installed, and running ok, and have installed additional modules, including the Apache::Bundle. When I put the line in mod_perl.conf, PerlModule Apache::DBI I can't start the web server. Dennis: Doctor, I think my server is sick, it cannot start Doctor: Does it have a high temperature? http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ 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
Re: Trouble with RegistryCooker.pm modper2.0
Kent, Mr. John wrote: Greetings, Today, 30-July-02, :Re-built both bleedperl and modperl from cvs per http://perl.apache.org/docs/2.0/user/install/install.html When attempting to run modperl get: [Tue Jul 30 13:08:08 2002] [error] [client 192.160.159.24] Use of uninitialized value in concatenation (.) or string at /users/webuser/bleedperl/lib/site_perl/5.8.0/i686-linux-thread-multi/ModPerl /RegistryCooker.pm line 549. This seems to be related to PerlSwitches -T which was in earlier releases but now is commented out Mea Culpa, please try again the cvs version, should be ok now. __ 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
Re: Subject: Re: hiding perl code
You are correct. If you... use Hidden::Module then use Data::Dumper to reconstruct most of the raw code. This would be about as useful as decompiling 'B' code. If you had access to the intrepreter directly, you could probably even capture the decrypt stream before perl compiles it, but all of that would take a degree of sophistication that is better used to make real money instead of hacking stuff apart. How about BZS::VeryObscure :-) Be it BZS::VeryObscure or BZS::VeryVeryObscure, all I was asking for is to tell the thruth in the docs probably somewhere at the top. I agree that for certain purposes this module may satisfy those who use it, but not all of them. __ 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
Re: Fwd: Re: Apache::DBI as a prerequisite
Simon Perreault wrote:
You wrote on 2002-04-30 to apache-modperl about Apache::DBI not being testable
while not under mod_perl. You said this:
That's normal. You cannot test modules that use mod_perl API without
running them inside mod_perl server. I've the same problem as you've
reported. This test suite is simple broken.
...
All Apache:: module authors should be moving to use the new Apache::Test
framework soon, since it lets you test the code under running mod_perl
server and works with both versions of httpd/mod_perl.
This is exactly my situation. I develop a module which requires Apache::DBI,
so I include it in my Makefile.PL like this:
WriteMakefile(
'PREREQ_PM'= {
'Apache::DBI' = 0,
},
);
But that prints a warning because Apache::DBI can't find Apache::module(),
which is only available under mod_perl.
My question:
1) Can you tell me (or guide me toward some information) how I can properly
add Apache::DBI as a prerequisite so that it doesn't print a warning (which
is the subjet of 90% of user emails)?
2) How can I test my module running Apache::DBI with Apache::Test?
I'll answer these in reverse:
2) See http://perl.apache.org/docs/2.0/devel/testing/testing.html
Though you can really rely on it once Apache::Test is released, which
will happen when mod_perl 2.0 is released.
1) That's an interesting problem. It seems that nobody has asked this
question before. Here is my take on it. If you like this solution I'll
add it to the docs.
Makefile.PL
---
use ExtUtils::MakeMaker;
# set prerequisites
my %prereq = (
Foo = 1.56,
);
# Manually test whether Apache::DBI is installed and add it to the
# PREREQ_PM if it's not installed, so CPAN.pm will automatically fetch
# it. If Apache::DBI is already installed it will fail to get loaded by
# MakeMaker because it requires the mod_perl environment to load.
eval { require Apache::DBI };
if ($@ $@ !~ /Can't locate object method/) {
$prereq{Apache::DBI} = '';
}
WriteMakefile(
NAME = 'Apache::SuperDuper',
VERSION_FROM = 'SuperDuper.pm',
PREREQ_PM = \%prereq,
# ...
);
__
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
Re: Apache::Status patch, in diff -u format (finally ;)
DH wrote:
Index: Status.pm
===
RCS file: /home/cvspublic/modperl/lib/Apache/Status.pm,v
retrieving revision 1.26
diff -u -r1.26 Status.pm
--- Status.pm 23 May 2002 16:14:56 - 1.26
+++ Status.pm 30 Jul 2002 12:39:07 -
@@ -514,6 +514,7 @@
mkdir $dir, 0755 unless -d $dir;
(my $thing = $r-path_info) =~ s:^/::;
+$thing =~ s{::}{-}g; # cause some OS's dont' allow :: in filenames
my $type = dot;
my $file = $dir/$thing.$$.gif;
Thanks, committed
__
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
Re: mod_perl2 DBD::Oracle problem
Atsushi Fujita wrote:
Hi all,
I am trying to use DBD::Oracle1.12 on mod_perl2.
But it doesn't work fine.
It shows error as following in error_log at $dbh = DBI-connect.
[error_log]
DBI-connect(ynt0) failed: (UNKNOWN OCI STATUS 1804) OCIInitialize. Check
ORACLE_HOME and NLS settings etc. at
/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42
[Mon Jul 29 20:15:37 2002] [error] 25703: ModPerl::Registry: `Cannot connect:
(UNKNOWN OCI STATUS 1804) OCIInitialize. Check ORACLE_HOME and
NLS settings etc.at
/yopt/httpd-2.0.39_prefork_perl5.6.1normal/cgi-bin/test1.cgi line 42.
[test1.cgi]
use DBI;
my $dsn = 'dbi:Oracle:';
my $user = 'username/password';
my $password = '';
$ENV{'ORACLE_HOME'} = '/u01/app/oracle/product/9.0.1';
$ENV{'ORACLE_SID'} = 'ynt0';
$ENV{'NLS_LANG'}= 'japanese_japan.ja16euc';
print ORACLE_HOME=$ENV{'ORACLE_HOME'}br\n;
print ORACLE_SID=$ENV{'ORACLE_SID'}br\n;
print NLS_LANG=$ENV{'NLS_LANG'}br\n;
print DSN=$dsn$ENV{'ORACLE_SID'}br\n;
$dbh = DBI-connect($dsn$ENV{'ORACLE_SID'}, $user, $password)
or die Cannot connect: .$DBI::errstr;
...
At first, I suspect that the reason is %ENV in this script.
But I set surely, and this output as following.
[Broser output HTML]
ORACLE_HOME=/u01/app/oracle/product/9.0.1
ORACLE_SID=ynt0
NLS_LANG=japanese_japan.ja16euc
DSN=dbi:Oracle:ynt0
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to
complete your request.
And if I turned off the mod_perl, it works fine on normal CGI-script.
This error occurred only mod_perl.
(I tested mod_perl1.26 apache 1.3.26, it worked fine...)
My machine is as following.
- perl5.6.1(non thread)
- DBI-1.30
- DBD-Oracle-1.12
- mod_perl1.99_04(DSO build)
- apache2.0.39(prefork)
[httpd.conf](is this wrong??)
LoadModule perl_module modules/mod_perl.so
...
IfModule mod_perl.c
PerlModule ModPerl::Registry
Location /cgi-bin
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
Options +ExecCGI
/Location
/IfModule
Do you suggest that %ENV is getting lost along the way? Or can it be
some other problem? I don't have Oracle to test with. Or can you think
of some other way to reproduce the problem without depending on Oracle
being installed?
Can you please test with the following two approaches:
1.
instead of using ModPerl::Registry, use Apache::Registry. Of course
configure Location to use Apache::Registry.
use Apache::compat;
use Apache::Registry; # hopefull you have mod_perl 1.0 installed
any change when you use the Apache::Registry from 1.0? Currently the
only difference (mainly) is that ModPerl::Registry doesn't chdir() into
the script's dir. (which eventually will change)
2. use a mod_perl handler
__
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
Re: $r-dir_config-(un)set issue...
simran wrote:
Hi All,
I have a situation where it is convinent for me to define a global
PerlSetVar in my httpd.conf and then unset it for particular virtual
hosts.
I used to use the following configuration successfully:
httpd.conf
--
Perl
use Apache::Server;
Apache-server-dir_config-unset(MyVar);
/Perl
-
That stopped working for me ever since we compiled
Apache/1.3.26 (Linix - Debian) with mod_perl/1.27
Has anyone else had the same issue?
On a similar note:
The following pices of code do not work:
-
code sample 1
--
1. sub handler {
2.my $r = instance Apache::Request(shift);
3.
4.$r-dir_config(MyVar = undef);
5.
6.$r-dir_config-unset(MyVar);
7.
8.$r-dir_config-set(MyVar = undef);
9.
10. }
s/$r-dir_config/$r-server-dir_config/?
What's really needed is probably PerlUnSetEnv.
None of lines 4, 6 or 8 actually unset the variable.
A collegue tells me that if a true value (for the key MyVar) is not
passed to set then it ends up returning the value of MyVar - but then
how i want to set the value of MyVar to be false. I would have though
that unset/set would have specifically done what i told them to
unset/set rather than do fancy things with truth values...
Ideas anyone?
simran.
--
__
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
Re: Problems with Apache/Mod_perl Server
Alfred Vahau wrote: Hello, I am posting this matter to the list because it takes so long from my end of the world to download the relevant information for trouble shooting. My problem is as follows: I downloaded mod_perl-1.26 and apache_1.3.24 in May this year. I followed all the instructions in the mod_perl guide on how to set up the server and had it running successfully without any problems. Now I decided to upgrade to mod_perll-1.27 and apache_1.3.26. I downlloaded from the mirror site at nagoya. I am following the same instructions which are, after uncompressing them: 1. perl Makefile.PL APACH_SRC = ../apache_1.3.26/src \ DO_HTTPD = 1 USE_APACI = 1 EVERYTHING = 1 Everthing goes smoothly. Then: 2. make make test make install The executiion is smooth until the test part which I believe fails and hence the install leg is aborted? The error output at the end is: ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 9 The t/logs/error_log reads [notice] Destruction-DESTROY called for $global_object Prototype mismatch: sub Socket::INADDR_ANY vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 328. Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 329. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 330. Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at /usr/lib/perl5/5.6.0/i386-linux/Socket.pm line 331. [Wed Jul 31 13:12:16 2002] [warn] [notice] child_init for process 3690, report any problems to [no address given] [...] I think the failure is due to incomplete mod_perl installation. of course. You run: make make test make install 'make test' fails, and therefore 'make install' is not run. simply run it. regarding the failing 'make test', you say that you run 5.6.1, and the error shows 5.6.0 in the path, how so? what your 'perl -V' says? I guess you have libs from 5.6.0 installed and they get on the way. __ 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
Re: mod_perl 2.0 api and extending method in Apache
Alexandre Dulaunoy wrote:
Hello,
I have look around the documentation of mod_perl 2.0 and I'm looking if
it's possible with the current mod_perl API to add a method (like GET,
HEAD) in apache to extend the functionnaly of the HTTP server ?
There is also some possibility with the new framework to add new protocol
(like the echo example in the mod_perl doc). But I just want to extend
existing (or add new) method... Is it possible ?
I'm not sure what you mean by extending, but look at mod_dav which
extends the HTTP protocol: modules/dav/main/mod_dav.c (inside the
httpd-2.0 repository).
In mod_perl 2.0 you can support new request methods, by simply
registering them. e.g. let's support the method 'TNT' in the response
handler:
Location /extend
SetHandler perl-script
PerlResponseHandler Apache::Extend
/Location
package Apache::Extend;
use strict;
use warnings;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Const -compile = 'OK';
use constant METHNAME = 'TNT';
sub handler {
my $r = shift;
$r-content_type('text/plain');
Apache::method_register($r-pool, METHNAME);
print Called with Method: . $r-method;
Apache::OK;
}
1;
Now, let's call:
perl -le 'require LWP::UserAgent; print
LWP::UserAgent-new-request(HTTP::Request-new(GET,
http://localhost:8002/extend/;))-content;'
Called with Method: GET
__
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
Re: Problems using Perl v 5.8
[EMAIL PROTECTED] wrote: Does it help to update mod_perl to 1.27? and if not, please send to the list the shortest possible script that reproduces the problem. Pasquale Pagano [EMAIL PROTECTED] on 07/29/2002 12:35:10 PM To: Modperl [EMAIL PROTECTED] cc:(bcc: Wesley Sheldahl/Lex/Lexmark) Subject: Problems using Perl v 5.8 Hi, We have some problems using: 1) Perl v 5.8 2) Mod_Perl v 1.26 3) Apache v 1.3.26 In particular: a) if we use simple CGI, everything works fine; b) if we use a custom handler for mod_perl, everything works fine; but if we try to use our CGI via Apache::Registry or Apache::PerlRun handler the code is ran correctly but we are able to send back to the browser only the HTTP header (everything else is missed). Here below an example of the http response -__- HTTP/1.1 200 OK Date: Mon, 29 Jul 2002 17:20:02 GMT Server: Apache/1.3.26 (Unix) mod_perl/1.26 Transfer-Encoding: chunked Content-Type: text/html; charset=ISO-8859-1 0 -__- Any of you have some hints?? Any help will be welcome, Regards, Lino PS: The same code works fine using Perl v 5.7.2. .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Pasquale Pagano CNR - Istituto di Elaborazione della Informazione Via G. Moruzzi, 1 - 56124 Pisa,Italy Area della Ricerca CNR di Pisa Tel +39 050 3152891 E-mail: [EMAIL PROTECTED] .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- -- __ 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
Re: make test problem error 111
Padraic Woods wrote: Hi, I'm trying to install apache + mod_perl + mod_ssl but get a error after running make test, I've tried skiping the make test but get a segmentation fault when I try starting apache. [...] ../apache_1.3.26/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log () gets absurdforkletting apache warm up...\c that's an interesing message: gets absurdfork where does it come from? no error_log is bad, have you tried following the install notes in: http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___openssl_ if you get a segfault, please follow the instructions at: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems __ 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
Re: while - modperl 2.0/Apache 2.0
ok, looks like your setup is fine.
Though I cannot seem to reproduce your problem. Indeed it seems that the
unbuffered output doesn't work. I'm checking on that. But I've devised a
better test that verifies that the requests aren't serialized. If you
run this hander by two clients at the same time, you should see the
lines in /tmp/test123 being interleaved by two processes. If this
doesn't happen and you get first 100 lines from process A followed by
process B's 100 lines than indeed we have a problem.
sub handler {
my $r = shift;
$r-content_type('text/plain');
local $| = 1;
open my $fh, , /tmp/test123 or die $!;
my $oldfh = select($fh); local $| = 1; select($oldfh);
my $i = 0;
while ($i 100) {
$r-print($$: $i \n);
print $fh $$: $i \n;
sleep 1;
$i++;
}
$r-print(__PACKAGE__);
close $fh;
return Apache::OK;
}
If this indeed doesn't work, please try the suggestion at:
http://perl.apache.org/docs/1.0/guide/debug.html#Using_the_Perl_Trace
so you can see where the second process is stalled. If you don't get
anything from this approach try to attach to the second process with gdb
and see where it is stack on the C calls level. Though I suggest that
you test with prefork and this setup:
IfModule prefork.c
StartServers 2
MinSpareServers 2
MaxSpareServers 2
MaxClients 2
MaxRequestsPerChild 0
/IfModule
__
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
Re: New mod_perl site and oddness with IE
[Let's move this thread to the docs-dev list, otherwise we make an OT noise at the modperl list, so, please, when replying to this email, remove the modperl address from it. thanks!] Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. --Jim please check if the problem exists on this url: http://www.bullitt.suite.dk/clean3/dst_html/docs/1.0/guide/performance.html if you have other browser software, please check and see if anything else is broken there as well. Allan, You are trying to solve it by applying HTML::Clean, which reduces the size of the page, right? But even if it does solve the problem for this particular page, what happens if the page grows, or there is some other page which is bigger, and no cleanup will make it small enough to make IE happy. __ 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
Re: How to see debug information in Net::Smtp?
[EMAIL PROTECTED] wrote: I use Net::Smtp module in my mod_perl script. When I run the fragment of my code from command line I can see the debug info. But running it on the production server I can't see the debug information. What can I do to see the debug info on the production server? look in the error_log file? __ 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
Re: How to see debug information in Net::Smtp?
Peter Werner wrote: and set your LogLevel to debug why? after all he is talking about perl logging, not Apache. LogLevel has nothing to do with it. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 10:27 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: How to see debug information in Net::Smtp? [EMAIL PROTECTED] wrote: I use Net::Smtp module in my mod_perl script. When I run the fragment of my code from command line I can see the debug info. But running it on the production server I can't see the debug information. What can I do to see the debug info on the production server? look in the error_log file? __ 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
Re: END subroutine in Apache::Registry
Hi Jim, The documentation is neither unclear nor confusing. However, the implication was not obvious (well... not obvious enough) when I first read this section three years ago. If you're sincere about wanting suggestions, here's mine: of course :) In addition to understanding the behavior of END blocks in Apache::Registry scripts, a script writer must realize that any module invoked via use or include may work differently than its designer intended, if that module contains END blocks. great, will add that. Though I've noticed that it works this way only if you 'use'. if you 'require' it's being ignored completely (not even run on the shutdown), is it just me or do you see the same? seems like a bug to me, unless I'm missing something. Thanks Jim! -Jim On Fri, 12 Jul 2002, Stas Bekman wrote: Jim Schueler wrote: I just read the fine print: Apache::Registry runs BEGIN subroutines just once per child process, but END routines run every time a script is run. The implication is that an otherwise robust module may behave unexpectedly when it's imported by an Apache::Registry script. Doesn't this cause problems for mod_perl users? There is no mention of this issue in either mod_perl_to_cgi or mod_perl_traps. Admittedly, most of the code in my END subroutines should probably be refactored into OO DESTROY subroutines anyways. But if not burned, I've been significantly scalded by this belated realization. I don't see anything on CPAN that can be easily applied to all of the modules that written. I'll happily fill that void, but I must be overlooking the obvious solution. Can anyone provide any insights? Please read: http://perl.apache.org/release/docs/1.0/guide/porting.html#END_blocks The special case is for registry scripts that include END blocks. If the the explanation at the above URL is unclear/confusing, please suggest how to improve it. __ 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
Re: TIPool / multiple database connections
Perrin Harkins wrote:
Elizabeth Mattijsen wrote:
Hmm... but you won't be able to fetch the $dbh from the thread. It
can only live in _that_ thread. You cannot pass objects between
threads. But you _can_ send queries to that thread, fetch a jobid for
that job and then obtain whatever was returned as a Perl datastructure.
(if anyone knows of a way to pass objects between threads, I'd really
would like to know)
Hmmm... That could really throw a wrench in things. If you have an
object based on a hash, and you share that hash, and you re-bless the
object in each thread, does that work? What if the hash contains
references to other variables. Do they need to be explicity shared as
well?
That's what I meant. Probably non need for Thread::Pool, at all. use a
shared datastructure, maintain a list of free and busy items and simply
hand pointers inside this datastructure to the threads asking for an
item. e.g.:
package DBI::Pool;
use threads::shared;
my @pool : shared;
sub init {} # pre-populate pool with N connections
sub get {} # return a ref to $dbh, grow the pool if needed
sub put {} # move the pointer from the busy list to the free list
won't this work? I guess Perrin is right in respect that the whole item
needs to be shared (deep-shared). can we have such an attribute/function
that will automatically traverse the datastructure and share it all? or
is this the case already with 'shared'?
Now since we want to have various connections, it can be:
my %pools : shared;
where each key is a unique identifier, compiled from the dbi connect's
DSN string and a value is the actual pool.
BTW, there is no more need for Apache prefix in Apache::DBI, this can be
a generic Pool class. I guess Apache::DBI can subclass DBI::Pool and add
things like connect_on_init(), but just to build the initial pool when
the process starts.
__
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
Re: Persistent Net::Telnet Objects in Apache2/mod_perl2
French, Shawn wrote: Stas Bekman wrote: It seems that you are after the same functionality as Apache::DBI, you want a pool of items that you want to be able to choose from. Look for threads::shared (perl 5.8.0), just create a shared hash with keys that you use for the map and the values for the actual connection objects. YES!!! That is exactly what I need! Where do I find perl 5.8.0 and threads::shared? I need a perl binary for windows since I'm without a compiler... Wait about one more week and it's going to be released. e.g. see http://use.perl.org/ As for the apache notes, I hope your right that it would be easy to implement, otherwise I can't upgrade to apache2 without some _huge_ workarounds... which are always nice to avoid :) Apache 2.0 wasn't released yet in any case. __ 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
Re: Getting to the Guide PDF on the new website
Gunther Birznieks wrote: At 09:24 PM 7/13/2002, Stas Bekman wrote: Gunther Birznieks wrote: I agree! It is great work. It looks really slick. :) Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the latest guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. eh? what do you mean? it's all there, go to: http://perl.apache.org/docs/1.0/guide/index.html click on the pdf button in the right upper corner and you get this: http://perl.apache.org/docs/1.0/guide/guide.pdf Notice though, that parts non-specific to mod_perl 1.0 has now moved to http://perl.apache.org/docs/general/index.html Oh I see it does work. I suppose the PDF buttons on every page is what confused me though. So if you go to the front-page of the docs section, just the front-page gets generated in a PDF, if you go to a page within the guide, then just that section gets generated. The only PDF icon that actually generates a full guide (and it is inconsistent with what the rest of the website PDF icons do) is the actually guide.pdf. A constructive suggestion would be that the icon for PDF on the main guide page should explicitly say PDF of entire guide or something other than the simple PDF icons on all the other pages of the website. Or perhaps remove the PDF icons entirely off the rest of the website. After all, who really wants to generate a PDF of a single HTML page they already read? Well, if you don't want to read the PDF of a single page, that doesn't mean that others think the same. People like reading of the paper and not the screen. The new site is based on docsets stacking. Each root node includes chapters and other docsets. Each root node builds the pdf of all its immediate leaf nodes (chapters). Each leaf (chapter) builds a pdf of itself. Notice that root nodes do *not* include chapters included in the nested docsets, otherwise the very root pdf will be of 50MB in size. I don't really follow your confusion. If you read the chapter 'help' and you click on the pdf icon you get this chapter in pdf. if you are reading the index page and click on the pdf you get the whole thing. It's just more flexible now than it used to be. I guess the only confusion might be with docsets that include no chapters, but only other docsets, so if you click on the pdf icon at /docs/1.0/ you get an almost empty pdf. But I guess people will learn how things work and find the infrastructure useful. __ 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
Re: TIPool / multiple database connections
Liz, should we move this thread to the perl-ithreads list so we can get some answers from the threads gurus? or p5p? I doubt Arthur is listening on this list. __ 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
Re: Working Directory
Matt Sergeant wrote: On Fri, 12 Jul 2002, Stas Bekman wrote: Josh Bernstein wrote: After just upgrading to mod_perl2 with Apache2. My current @INC path includes a . on the end, which should reference the current working directory, and therefore correctly locate include locate in the script's working directory. The problem is that the Working Directory is set to /. My question is how can I set the working directory to be the location of where the script is running. (This would make mod_perl correctly locate file that I have included in the running script ie: require ./file.pl) Can this be done from within Apache? I've tried variations of PerlSetEnv but I can't seem to get it to work. I've even read the mod_perl2 user's guide. Thanks for your help.. chdir is not a thread-safe function, (there is only one CWD per application) therefore the new ModPerl::Registry doesn't chdir to the dir of the script. We have discussed various workarounds on the dev list, but none of them has been applied yet. http://mathforum.org/discussions/epi-search/modperl-dev.html (search for 'chdir thread') Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. __ 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
Re: Apache SSL - how to start it in -X mode
[EMAIL PROTECTED] wrote: How to restart SSL Apache in -X mode? This is a wrong forum. See: http://httpd.apache.org/lists.html#http-users __ 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
Re: Working Directory
Elizabeth Mattijsen wrote: At 06:10 PM 7/16/02 +, Stas Bekman wrote: Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. Check out Arthur's article on Perl.com: http://www.perl.com/pub/a/2002/06/11/threads.html I read the article ;) The article doesn't say that there is going to be a module that will do all this work for you. I just wanted to share the happy news that such a module is about to emerge. Most of the people don't care how things are implemented, they just want to know that the API they use is thread-safe, which is how it should be with chdir() and friends. Though you realize that that this wrapper will incur a certain overhead, which needs to be benchmarked. And if that overhead is of any significant value, we should provide a switch to turn if off for those who don't rely on chdir() and therefore can get a better performance. I'm talking mainly about the Registry family in this case, but I can see that this functionality could be provided on the mod_perl core level (PerlSafeCwd flag?). __ 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
Re: worker thread
Pasquale Pagano wrote:
We are trying to use:
1)Apache 2.0.39 compiled with the option --with-mpm=worker
2)with modperl 2.0
under Sun Solaris 2.8 with Perl 5.8 RC2.
Although everything seems to work fine, the creation of a custom worker
thread takes more or less 2 minutes.
Here below a section of the code used:
my $t1 = new Thread(\my_thread,'t1');
my $t2 = new Thread(\my_thread,'t2');
$t1-join();
$t2-join();
sub my_thread{
my $name = shift;
print I'm $name\n
return $name: done\n;
}
In the example above, each new thread call takes about 2 minutes.
May I ask, why do you create these threads? Under worker you already
have the threads created for you and and the perl interpreters handed to
you when you need them.
BTW, what happens if you run the same code from the command line?
__
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
Re: relative path not accepted in mod_perl2 ?
[EMAIL PROTECTED] wrote: just found out the deeper reason - mod_perl now always has path=/ which is unexpected behaviour. While I can filter out the actual path from the cgi-environment I dont understand this .. See the parallel thread on the same topic. http://mathforum.org/epigone/modperl/smansheezhing Things will work as expected by the time mod_perl 2.0 is released. [funny that mathforum's engine has mixed this thread with a thread with the same title but from 5 years ago. Looks like the time has crossed itself] -- __ 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
Re: Apache::Registry and Apache::PerlRun
Boex,Matthew W. wrote: question, can i have both Registry and PerlRun running in the same environment? i have my cgi scripts running under Apache::Registry in one directory, and want to run a legacy cgi script under PerlRun in another directory. is this possible? matt of course. That's how it works. You can even run the same scripts under different handlers. Have you tried and it didn't work 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
Re: R: worker thread
Pasquale Pagano wrote: From the command line, it works very well. We are impleminting a very complex digital library system. In same cases, we want to start parallel threads in order to minimize the wait. Let me try to explain with an example. 'A' start 4 threads, each of which prepares, and sends a request to another server, and then collects its result. When all threads will be terminated, 'A' will merge the 4 results. Is now more clear? sure, thanks your problem is that you use the *old* threads (5005threads, pre-5.6.0), whereas mod_perl 2.0 is using ithreads (5.6.0+). my $t2 = new Thread(\my_thread,'t2'); ^^^ do 'perldoc threads' with perl-5.8.0 __ 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
Re: Purify, Perl and mod_perl
Perrin Harkins wrote: [...] My question is this...can I run my application using this purified perl under mod_perl to track down potential memory leaks and other problems? You probably don't have any memory leaks. Most things that people refer to as leaks are just normal growth. A leak is when an area of memory gets lost because the program that allocated it forgets to free it. or cannot free it because of the closure or a circular reference, which seems to be the case with the bug in Apache::Request reported by Dave Rolsky. [...] A number of the most common sources of memory growth are explained in the guide: http://perl.apache.org/docs/1.0/guide/performance.html#Improving_Performance_by_Prevention Plus Apache::Leak, whose reports should be carefully analyzed because not everything that it reports as a leak is actually a leak: http://perl.apache.org/docs/1.0/guide/debug.html#How_can_I_find_out_if_a_mod_perl_code_has_a_memory_leak __ 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
Re: problem compiling modperl2.0
Harry Zhu wrote: I am trying to create a test environment for modperl2.0/apache2/perl5.8 under RedHat7.3. As root, I did the first step, download using the cvs to get the modperl-2.0, httpd-2.0 and apr, apr-util (placed in httpd-2.0/srclib). make make install is fine. I using rsync to get the Perl, and the 'make's are fine and linked to /root/bleedperl/bin/perl. The install LWP under the new perl is also fine. Now come to the modperl2.0: root /root/bleedperl/bin/perl Makefile.PL MP_AP_PREFIX=/root/httpd-2.0 Reading Makefile.PL args from @ARGV MP_AP_PREFIX = /root/httpd-2.0 Configuring Apache/2.0.40-dev mod_perl/1.99_05-dev Perl/v5.8.0 And a bunch of the following !!! Unable to open /root/httpd-2.0/include/apr.h: No such file or directory Have you configured httpd-2.0 already? do that first before moving onto modperl __ 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
Re: [modperl2] Perl Connection Handlers for SSL connections
Pete Rothermel wrote:
I've got the example echo() handler working for a non-HTTP protocol as
outlined on the new web site:
http://perl.apache.org/docs/2.0/user/handlers/handlers.html#Command__Protocol__Phases
Anybody have a similar example for the same protocol handler over SSL?
the echo protocol working over the socket skips filters, so it won't
work with SSL.
at the above URL scroll down to the Apache::Eliza2 example, which uses
bucket brigades and therefore should work over SSL.
I didn't have a chance to document it yet, but for simple things you
just change the code inside this snippet:
if ($data) {
$data =~ s/[\r\n]*$//;
$last++ if $data =~ /good bye/i;
$data = $eliza-transform( $data ) . \n\n;
$bucket = APR::Bucket-new($data);
}
the rest most likely will stay unmodified.
__
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
Re: while - modperl 2.0/Apache 2.0
Udlei Nattis wrote:
hi
sorry my english
i have one problem
when i open 2 browsers intance and access my perl script
instance 1 run script OK
instance 2 waiting instance 1 finalize to run :/
i need run simultane 2 instance
(modperl 2.0 dev 5 / perl 8 rc 3 / apache 2.0 prefork or worker )
how many servers do you run? Are you testing this in the single server
mode? Seems that you run only one server or only one process with one
thread.
a few comments regarding the code (irrelevant to your problem):
#!/usr/bin/perl
use Apache2;
this should go into startup/httpd.conf.
$| = 1;
my $r = Apache-request;
that should be just:
my $r = shift;
since your code is wrapped into sub handler { }.
what you are doing is expensive under threads.
__
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
Re: Working Directory
Josh Bernstein wrote: Sounds great? Does he have anything that I could play with? I'm really dying for that chdir(), my programmer says he depends on that functionality. I'd even volunteer to do some benchmarks and what not associated with the extra overhead of making the function thread safe. He should probably announce it soon, when he returns from vacation. why don't you test with prefork for now? and Apache::compat + Apache::Registry from 1.x? If its not really yet, what do you feel is currently the best work around? I've read through the archives and I'm just try to figure which one to use... there are no workarounds to having a thread-safe cwd, other than using full paths. -Josh Stas Bekman wrote: Elizabeth Mattijsen wrote: At 06:10 PM 7/16/02 +, Stas Bekman wrote: Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. Check out Arthur's article on Perl.com: http://www.perl.com/pub/a/2002/06/11/threads.html I read the article ;) The article doesn't say that there is going to be a module that will do all this work for you. I just wanted to share the happy news that such a module is about to emerge. Most of the people don't care how things are implemented, they just want to know that the API they use is thread-safe, which is how it should be with chdir() and friends. Though you realize that that this wrapper will incur a certain overhead, which needs to be benchmarked. And if that overhead is of any significant value, we should provide a switch to turn if off for those who don't rely on chdir() and therefore can get a better performance. I'm talking mainly about the Registry family in this case, but I can see that this functionality could be provided on the mod_perl core level (PerlSafeCwd flag?). __ 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
Re: New mod_perl site and oddness with IE
Jim Helm wrote: Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. An older version I tracked down with Google (http://www.apache.jp/perl/guide/performance.html) which is also 300K+ doesn't have the same problem - just to show that it's not purely the raw size of the page that is the problem. Just a little feedback for the new site (which is great, btw). If it's just me with the problem, I'll go find a rock to hide under. :) Is the size of the page causes the trouble? I don't have IE to try so hopefully someone will help us out here. What happens if you shorten the content of the page? My guess is that IE simply cannot cope with a long page and the current complex stylesheet (because as say it works fine with the same page and a simpler stylesheet, which includes no layout instructions). Suggestions on how to fix that are welcome. __ 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
Re: Accessing mod_ssl information from mod_perl modules
Byron Ellacott wrote: Hi, I've been trying rather unsuccessfully to write an Authen handler that is able to detect an SSL connection and use the SSL certificate serial as an index into a database table. The problem I'm facing is how to discover the SSL connection information in an Authen handler. At a later phase, the SSL certificate is available in $r-subprocess_env(), in various forms. I can, for example, turn on SSLOptions +StdEnvVars and access $r-subprocess_env(SSL_CLIENT_M_SERIAL) and get what I'd expect. However, authenticating and authorizing in the Response phase has several downsides. The first is that there are phases specifically for this work. The second is that if (when) I want to replace SSL authentication with Basic, or with JRandomAuthenModule, I'll have to modify my Response handler, or have it do an ifthenelsifthenelse block. So, from reading the mod_ssl source, it appears all the information I want is attached to the request object in a pool. APR::Pool has no manpage, I can't figure out how APR::Pool ties into the mod_perl source code, and basically I'm completely stuck with no idea how to, or even if I can, access this information. You are talking about mod_perl 2.0, aren't you? Please make that clear upfront, preferrably in the subject of your post. What do you need APR::Pool for? What are you trying to do (code sample) and failing to? APR::Pool is just a class that encapsulates the apr_pool objects. There is not much you can do with these objects. You can find the sample usage in t/response/TestAPR/pool.pm. As previously mentioned here, currently if you need to know how a new Apache:: or APR:: class works, your best source of information is the test suite, unless you prefer to look at the source code. The new manpages won't be written until we get the automated docs generation based on httpd-2.0 header files working. There are too many manpages and the API is still changing so it doesn't worth doing any manual work before it gets frozen. __ 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
Re: TIPool / multiple database connections
Tim Keefer wrote: I need to have several database connections within one modperl application (sharing the connections across all modules would ideal). Could anyone suggest a way to cache these connection with Apache2/modperl2 on win32? The modperl2 docs talk about a TIPool module along with a DBIPool module. Has anyone had success using these modules? I can't seem to find them in the apache2/modperl2 distribution from Randy Kobes. Thanks for any help, If you are talking about prefork, Apache::compat with Apache::DBI should do. If you are talking about threaded mpms, the TIPool idea stays just as an idea, because now we have threads::shared that will do. Just give it some time because there is lot of work being done in that direction as you read this. Gerald Richter and Tim Bunce are working on the thread-safe DBI. A few folks at p5p are creating a bunch of new modules around threads:: and threads::shared::, just yesterday a new module: Thread::Pool was released by Elizabeth Mattijsen. Which seems to be what's needed for Apache::DBITPool. Feel free to join the efforts and make things happen faster. __ 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
Re: TIPool / multiple database connections
Elizabeth Mattijsen wrote: At 12:18 AM 7/16/02 +, Stas Bekman wrote: ...A few folks at p5p are creating a bunch of new modules around threads:: and threads::shared::, just yesterday a new module: Thread::Pool was released by Elizabeth Mattijsen. Which seems to be what's needed for Apache::DBITPool. Hmmm... I guess you're right. I hadn't thought of applying Thread::Pool in this situation, but it sure makes sense. This would however imply that jobs would be submitted from different threads. That _should_ work, but I just realised that I don't have a test-case for that. Will work on one and let you know the result. I think that's a reverse case, the pool creates the dbh items (tools) and workers pick the items use them and then put back when they are done with them. So it's the pool who creates the things. btw, one thread should be able to pick more than one item at once. but in this particular case of DBI, I think there should be a different pool for each connectin group. similar to what Doug has suggested in his original TIPool prototype in the overview doc. __ 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
Re: Persistent Net::Telnet Objects in Apache2/mod_perl2
French, Shawn wrote: Hey everyone, It's me again... the persistent telnet mod_perl newbie! (http://msgs.securepoint.com/cgi-bin/get/apache0205/204.html) I have implemented my project using persistent telnet connections (one for each user session accessible throught the session to perform various functions through telnet) on win2000: Apache/1.3.26 (Win32) mod_perl/1.27_01-dev Now for my next trick! When I started I didn't realize that mod_perl on win32 could only handle one request at a time!!! This is obviously not acceptable for deployment. So, I would like to upgrade to Apache2/mod_perl2 to take advantage of the multi-process mod_perl model that the _very_ kind Randy Kobes told me about (http://groups.google.ca/groups?dq=hl=enlr=ie=UTF-8oe=UTF-8selm=afv3gu% 24qt2%242%40canopus.cc.umanitoba.ca). However, with a multi-process model, I'm not sure how I will be able to keep a user's telnet-session-object accessible throughout multiple requests. Currently it's not a problem since there's only one process for ALL mod_perl requests. In Apache2/mod_perl2 there will be more than one process so I need some sort of mapping to make sure my clients are aways served by the same process. Is this possible? Am I in way over my head (again!!) ? It seems that you are after the same functionality as Apache::DBI, you want a pool of items that you want to be able to choose from. Look for threads::shared (perl 5.8.0), just create a shared hash with keys that you use for the map and the values for the actual connection objects. If you can have the client persist the connection, you can implement a real protocol module. e.g., see: http://perl.apache.org/docs/2.0/user/handlers/handlers.html#PerlProcessConnectionHandler Another problem is that I have also been informed that my _MUCH_ used apache_notes function in php will not be available to me in Apache2 (http://bugs.php.net/bug.php?id=17557). I realize this is an Apache2 thing, but I was wondering if anyone here knows of a workaround that will allow my php scripts to communicate with mod_perl (and vice-versa) until (hopefully) the function is ported to Apache2. From what I understood mod_php in 2.0 is going to be implemented as a filter. Is that right? Is that the reason why notes won't work anymore? I don't think so. Practically there should be a problem to implement this feature, because you have a connection object which persists for the whole connection, so you should be able to register some data in this object and then retrieve it later in some other phase/filter. in mod_perl handler you simply get the connectin object and stick something into the notes, e.g. inside request handlers: my $r = shift; my $c = $r-connection; $c-notes-set(mod_perl = 'rules'); and then later for example in a mod_perl filter handler you do: my $f = shift; my $c = $f-connection; my $is = $c-notes-get(mod_perl); $f-print(mod_perl $is); you should ask php folks why cannot they get c-notes working, the C datastructure is all there waiting to be used. __ 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
Re: duplicate output with Registry.pm
Eric Frazier wrote: Hi, I know this is a FAQ sort of question, but I can't find it in the faq and I am going nuts. Like I know I know the answer to this, but I just can't get it back in my head. Any output under Registry.pm gets duplicated. One page = two doubled pages. I am using CGI::Application and HTML::Template, but I believe this is a mod_perl problem since it doesn't happen when I use the same scripts in a regular cgi-bin. Also if someone knows where I can find this on the web I would be grateful. I just can't seem to get the keywords right today. Looks like an application logic bug. Can you strip the extra elements (HTML::Template, etc), create a *short* script that reproduces the problem and post it to the list? __ 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
ANNOUNCE: mod_perl guide v1.32
This is probably the last announcement regarding the mod_perl guide's changes, because on the new mod_perl site all the changes are almost instant and the need for releases is pretty much not needed any more. Therefore remember to refer to the Changes file if you want to know what has changed since the last time you've read some docs. That said, there will be no more separate mod_perl_guide's releases on CPAN as they used to be, since the guide has now been merged into the mod_perl documentation. It's possible that we will start releasing the modperl-docs repository on CPAN instead. We will see. Meanwhile you can download and install locally the guide and the rest of the docs here: http://perl.apache.org/download/docs.html So here are the changes in the guide since Nov 15 2001: =head1 Jul 14 2002 ver 1.32 * snippets.pod: o new recipe: File Upload with Apache::Request [Rich Bowen] * cookbook o ported Passing Arguments to a SSI script from the modperl faq * method_handlers.pod o moved here from the faqs * databases.pod o correct the notes regarding Opening Connections With Different Parameters for Apache::DBI. Must localize local changes. * getwet.pod o a new chapter to get you started fast * porting.pod o add a new section Preventing Apache::Constants Stringification [Per Einar] o add a new section presenting a hackish solution for libraries collision, via do() or %INC mangling. o bring the warnings section up to date with perl 5.6 (Rafael Garcia-Suarez) o cover the 5.6's CHECK block in addition to INIT (Rafael Garcia-Suarez) * troubleshooting.pod o solution to the 'readdir()/opendir() not working' problem (Louis Semprini) o clearify how to solve the segfault problem caused by built-in mysql support in mod_php (Paul Buder) * modules.pod o extend on Apache::Filter (Per Einar Ellefsen) * config.pod o adopt sections from the modperl faq and rewrite the whole security configuration section o extended on method handlers (Per Einar Ellefsen) o show an example on how to load the mod_perl related config only when mod_perl is loaded (Rafael Garcia-Suarez) o More information about PerlSetEnv/PerlPassEnv/PerlSetupEnv w/ practical example[Per Einar] o Extend on PerlSetVar/PerlAddVar but more importantly, add information about subrequests w/ lookup_file and dir_config provided by Matt Sergeant in this thread: http://mathforum.org/epigone/modperl/praxdwumze [Per Einar] * debug.pod o extended on curinfo macro (Per Einar Ellefsen) * help.pod o chroot(1) urls o jail(8) urls (Andrew McNaughton) o link to the internal resources (Per Einar Ellefsen) * install.pod o James G Smith has uploaded his Apache Builder to CPAN, update the download links, to reflect this change. * performance.pod o add more benchmarking tools refs: HTTP::WebTest, HTTP::Monkeywrench, HTTP::TestEngine, HTTPD::Bench::ApacheBench o update the benchmark in the section Apache::args vs. Apache::Request::param vs. CGI::param using Apache::Request 1.0. o Update the documentation on Apache::SizeLimit and Apache::GTopLimit which now both sport the shared and unshared memory thresholds. o added a new section: Potential Drawbacks of Memory Sharing Restriction * intro o major additions to the introduction, including information about the C API and the Perl API and Apache::PerlRun, as well as some more corrections of links relative to the site. [Per Einar] * guide o most of the internal links were changed to use the whole title and not only first few words. The new build system support this. o The documents themselves are now referenced as guide::something, e.g. guide::modules, because now the guide is a part of a much bigger collection of the documents, which need to be fully qualified, so each document can link to other documents in different projects/subprojects. o added descriptions to all chapters (Per Einar Ellefsen) o The document structure has been reorganized and decentralized: some general chapters have left the Guide in favor of the General Documentation section, which is where you should look now for some of the sections that were earlier here [Thomas Klausner] * Minor corrections: o remove qw() or variables list in general::perl_reference (Tim Noll [EMAIL PROTECTED]) o install: (Per Einar Ellefsen [EMAIL PROTECTED], Karl Olson [EMAIL PROTECTED]) __ 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
ANNOUNCE: Perl 5.8.0 Release Candidate 3
). If all tests are not successful, you may get a more detailed report by changing to the t/ subdirectory and running the harness script, something like this cd t ./perl harness You may need to set up your dynamic library path before that (the final message of make test should tell all the needed details). The more detailed report will be very useful when your report problems. Knowing your exact configuration is essential, too: usually running the myconfig script from the build directory produces this information. Note that some systems or configurations have known problems, see perldelta for details, no need to report them. In case you still see errors, please document them via the perlbug system, as detailed in the INSTALL file, section Reporting Problems. Finally note that if you happen to have a less common platform, like some of the rarer UNIXes, or something even more exotic, we will be glad to hear even of successes, not just about possible problems. =head2 Installing Once you are happy with the test results of Perl itself (or you are just feeling extraordinarily brave), you may consider installing it. The Perl development team has tried to guarantee that popular Perl applications like CGI, LWP, mod_perl and DBI/DBD work with 5.8.0. Note work, not necessarily work without warnings: for example DBD::Oracle works, but during compilation and testing you may see various warnings. Also in some cases not all the functionality of the modules may be available (yet). However... THIS IS A REAL NEW PERL RELEASE THAT IS BINARY INCOMPATIBLE WITH ANY PREVIOUS PERL RELEASE. THIS MEANS THAT YOUR OLD EXTENSIONS (.xs code, those Perl modules requiring a C compiler) WILL NOT WORK AND WILL HAVE TO BE RECOMPILED. (Pure Perl modules should continue working.) INSTALLING THIS PERL RELEASE WILL OVERWRITE YOUR CURRENT PERL RELEASE. (For example, /usr/bin/perl will become Perl 5.8.0.) DO NOT INSTALL THIS INTO PRODUCTION USE UNLESS YOU REALLY MEAN IT. If you still feel like installing this, you can do so by make install. If you want to install this, but want to install it into some less dangerous place (and not overwrite your current installation), do the following make realclean sh Configure -des -Dprefix=/test/perl580 -Uinstallusrbinperl make all make test and then the make install. The -Dprefix will place the Perl installation at the said directory (the Perl executable will be /test/perl580/bin/perl), and the -Uinstallusrbinperl will avoid overwriting /usr/bin/perl with a copy of the Perl 5.8.0 executable. =head1 Testing The Perl Installation You should test both your own code, and other code that you use. =head2 Testing Your Own Code Test your own code with perl 5.8.0, but in case of surprises read the perldelta.pod carefully before judging something as a bug. In some cases the behaviour of Perl has changed. =head2 Testing Perl Modules You should try reinstalling your favourite CPAN modules to guarantee that they will continue working under Perl 5.8. Note that if you find some module either failing its tests or you see the tests emitting warning messages, please first and foremost report these problems to the author of the module. Advise him/her about the impending 5.8.0 release and where to get the RC3 (you might for example point the author to this very message). Since there are hundreds of modules available, the Perl 5 developer team is not qualified to be experts on all of them; it is much faster if the module author resolves any problems. In some cases you may also consider contacting some mailing lists to ask for help (and to spread awareness of the upcoming 5.8.0), for example if your operating system or the modules have mailing lists of their own. =head2 That's it. =head1 AUTHOR Jarkko Hietaniemi on behalf of the Perl 5 developer team =cut __ 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
Re: ANNOUNCE: the new perl.apache.org is alive now!
Nick Tonkin wrote: The content seems great. But whatever font you've used is rendering skinny and pixelated and hard to read and makes me want to egt of the site asap ... why not leave font face undetermined so the font that each has chosen for his platform is employed? Agreed 100%, my fonts suck too :( When I've changed the font-family to pick the good fonts on linux, users on other platforms didn't like that. We were thinking to try removing font-family completely. Does anybody know of any problems with this approach? __ 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
Re: Working Directory
Francesc X.Noria wrote: On Thu, 11 Jul 2002 16:56:38 -0700 Josh Bernstein [EMAIL PROTECTED] wrote: : /. My question is how can I set the working directory to be the : location of where the script is running. (This would make mod_perl : correctly locate file that I have included in the running script ie: : require ./file.pl) Can this be done from within Apache? Maybe you could use this trick: use FindBin qw($Bin); use lib $Bin; You cannot. FindBin does its magic in the BEGIN block, which will run only once under mod_perl. http://perl.apache.org/release/docs/1.0/guide/snippets.html#More_on_Relative_Paths you can do 'do FindBin', but you add the overhead. __ 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
Re: END subroutine in Apache::Registry
Please read: http://perl.apache.org/release/docs/1.0/guide/porting.html#END_blocks The special case is for registry scripts that include END blocks. If the the explanation at the above URL is unclear/confusing, please suggest how to improve it. It's pretty clear, and the bit about BEGIN blocks is right next to it, but it might be worth adding a note about the imbalance between BEGIN blocks and END blocks under Apache::Registry to cover this issue. I don't think there is really a need, but if we do so, the imbalance is between END and all *other* special blocks, like INIT, CHECK, BEGIN etc. So I believe that what is says now is just fine. The registry END block is the black sheep... __ 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
ANNOUNCE: the new perl.apache.org is alive now!
As you may know, the work on the new mod_perl site started in September 2001, and after almost a year we are glad to present to you the outcome of this work at the expected location: http://perl.apache.org/ and say good bye to the old site, which has now retired, but still can be retrieved from http://cvs.apache.org/snapshots/modperl-site/. This new site is a result of a collaborative effort of the mod_perl community. Thank you all! Without you the new site won't be as good as it is now. Special acknowledgements go to the following folks: Allan Juul Bill Moseley Jonathan M. Hollin Per Einar Ellefsen Thomas Klausner The new mod_perl site's goal wasn't only to create a nice design, but mainly to improve its documentation organization and navigation aspects, because of the ever-growing amount of documentation that the mod_perl community generates. One of the important new features is that any documentation modifications are now almost instant, so you don't have to wait for the next guide's release to get the latest fixes and improvements. We also hope that the new site will bring more contributors to the documentation. You will find the mod_perl documentation under http://perl.apache.org/docs/ which is split into sections specific to mod_perl 1.0 and 2.0, and a section for general docs which apply to any mod_perl generation. Under each generation specific you will find another separation for user documents, core developers, API and OS-specific docs, which didn't fit into general docs. The new tutorials sections sports a few interesting features, which aren't strictly mod_perl but very useful to most mod_perlers. And of course we now have the feature: What's mod_perl: http://perl.apache.org/start/index.html, which is our newbie orientation procedure, which they hopefully find useful. If you would like to build the site locally, read: http://perl.apache.org/download/docs.html If you have any questions regarding the use of the new site, read: http://perl.apache.org/help/help_with_site.html For other questions see: http://perl.apache.org/help/index.html I'd like to point your attention to the 'Short Cuts' menu on the left, which I hope you will find useful. The main menu includes the 'Site Map' and of course use the force^H^H^H^H^Hsearch if you don't know where to find things. The site includes many more new features, I don't want to spoil your (hopefully pleasant) surprises. Enjoy your new site, mod_perlers, and please help to spread the word. __ 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
Re: solaris9+apache2+mod_perl2
Well I commented the little switch statement what was giving me the problems and all seems to be resolved. Josh, have you tried with the latest cvs as I've suggested, it seems like you didn't. [...] Stas Bekman wrote: Josh Bernstein wrote: Hey All, I'm getting this error when I try to make mod_perl2, under solaris 9 ... Any one have any ideas? Oh and I'm running Solaris 9, with Apache 2.0.40cvs, it should also be noted that the mod_perl was pulled from CVS on July 8th. Is this just a broken build? Try again 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
Re: nice mod_perl statistics to share
Kevin Berggren wrote: Stas Bekman wrote: I've just updated the mod_perl with the latest stats and I'm glad to say that the results are nice, so you can show your bosses that they did the right choice (or should) ;) This is the netcraft.com: http://perl.apache.org/release/outstanding/stats/netcraft.html With the new perl.apache.org site, this seems to have disappeared. Any chance it has a new home? The /release/ prefix was for only for the preview stage. Simply remove this prefix segment and you get the same page on the new site. We don't want to add redirects for /release/, so people will not link to /release, it was a temporal thing after all. All the stats are here: http://perl.apache.org/outstanding/stats/ __ 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
Re: ANNOUNCE: the new perl.apache.org is alive now!
Gunther Birznieks wrote: I agree! It is great work. It looks really slick. :) Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the latest guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. eh? what do you mean? it's all there, go to: http://perl.apache.org/docs/1.0/guide/index.html click on the pdf button in the right upper corner and you get this: http://perl.apache.org/docs/1.0/guide/guide.pdf Notice though, that parts non-specific to mod_perl 1.0 has now moved to http://perl.apache.org/docs/general/index.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
Re: ANNOUNCE: the new perl.apache.org is alive now!
Nate Campi wrote: I hate to be a party pooper, but I single handedly brute upgraded www.wired.com from Vignette Storyserver 5.0 to V/6 this month - it's not mod_perl. The new page is incorrect. I do the ServerTokens Min thing to hide what modules we run. If the authors of the page want to ask me about different mod_perl stuff we do at Wired/Lycos feel free to contact me off list. We have some cool stuff. sure, please send the updates and the page will be adjusted. Nobody expects this page to stay the same. We did remove many sites that used to be there, either because they couldn't be reached or because they didn't seem to be running mod_perl. -- __ 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
Re: ANNOUNCE: the new perl.apache.org is alive now!
fist, let me say: Great Job! the new site looks fantastic, a *vast* and long-awaited improvement. ;) i still notice, however that the *content* of the Sites Running mod_perl page doesn't seem to have been updated. about 6 months ago, i sent notices about two sites that we (Vanguard Media) had launched to the email address that used to be on that page, but they were never included. is this being actively maintained now? Very actively. should i re-send now to the docs-dev mailing list? Yes, please. While you've raised this issue, I'd like to remind everybody that we want your (long) success stories for: http://perl.apache.org/outstanding/success_stories/index.html or simply (short) reports of cool sites running mod_perl for: http://perl.apache.org/outstanding/sites.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
Re: New Website
Joshua Bernstein wrote: Incredible Job on the new site. If there is anything I can help with (Documentation etc...) Please let me know.. Everybody can help. Go read the site, see what's missing, incomplete, unclear and send the updates/new material in. e.g., do you know of any new mod_perl based products that aren't listed at: http://perl.apache.org/products/products.html do you know of mod_perl training companies, isps supporting mod_perl, commercial mod_perl support, etc.: http://perl.apache.org/help/index.html Especially we need help populating the new 'Tutorials' section: http://perl.apache.org/docs/tutorials/index.html and Offsite resources, where mod_perlers should go for solving their problems in non-mod_perl domains, so for example we can use that page to send the offtopic posters to: http://perl.apache.org/docs/offsite/index.html Overall, think what could be done better, what can help others, etc. Innovate and contribute! __ 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
Re: Working Directory
Josh Bernstein wrote: After just upgrading to mod_perl2 with Apache2. My current @INC path includes a . on the end, which should reference the current working directory, and therefore correctly locate include locate in the script's working directory. The problem is that the Working Directory is set to /. My question is how can I set the working directory to be the location of where the script is running. (This would make mod_perl correctly locate file that I have included in the running script ie: require ./file.pl) Can this be done from within Apache? I've tried variations of PerlSetEnv but I can't seem to get it to work. I've even read the mod_perl2 user's guide. Thanks for your help.. chdir is not a thread-safe function, (there is only one CWD per application) therefore the new ModPerl::Registry doesn't chdir to the dir of the script. We have discussed various workarounds on the dev list, but none of them has been applied yet. http://mathforum.org/discussions/epi-search/modperl-dev.html (search for 'chdir thread') If you want to extend @INC to include some extra paths change it during the startup. It's possible that we will have a special version of registry (ModPerl::RegistrySafeChdir) which does the right thing but you pay the price of a worse performance, read more about it here: http://www.perl.com/lpt/a/2002/06/11/threads.html It's also possible that there will be ModPerl::RegistryNonThreaded or something like that, which will chdir just like the registry in mod_perl 1.0 did, which will restrict your code to run only on the prefork mpm. The idea that the main ModPerl::Registry should work identically across different mpms. __ 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
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Kent, Mr. John wrote: Greetings, Have noticed that modperl-2.0 servers running on Solaris 2.7 start off at 23M in size. Five hours later they were at 38M. If allowed to continue they could eventually use up all available RAM and crash the system. Stopping then restarting returned them to 23M. Has anyone else encountered this and is there a recommended solution other than periodically stopping and starting? Are you using the prefork mpm or a threaded one? If this is a prefork, use Apache::SizeLimit (or Apache::GTopLimit) just like in 1.0. See: http://perl.apache.org/release/docs/1.0/guide/performance.html#Preventing_Your_Processes_from_Growing If you are talking about threaded mpms, we will need to develop new tools to restrict the size of the perl interpreters in the pool. Other than try to figure out if your code (or the server) doesn't leak. __ 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
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Perrin Harkins wrote: Stas Bekman wrote: If you are talking about threaded mpms, we will need to develop new tools to restrict the size of the perl interpreters in the pool. I was thinking about that too. Are there hooks for causing an interpreter to exit? Is it safe to simply call CORE::exit? I'd like to make SizeLimit work for the threaded MPMs if possible. I think the idea was to have a special thread running whose only purpose is monitoring the pool of idle interpreters. Inside that thread you could have various processes happening for each process: - garbage collection (walk the optree and free big chunks of reserved/unused memory, other optimizations) - destroy interpreters that have too much non-shared memory, etc - reload modified modules? - etc.. I think this was somewhat discussed about a year ago. I'm not sure if this approach can be somehow piggy-backed into Apache::SizeLimit so users will be able to run pretty much the same setup for threaded and non-threaded mpms. I believe that we can add a Perl space hook that sets a flag that condemns an interpreter to death. When an interpreter is put back into the pool, this flag can be checked and modperl_interp_cleanup() called if that flag is set, thus killing the interpreter. I'm not sure if CORE::exit will work, most likely not, because it'll probably unsync the pool state. Need to try though. __ 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
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Perrin Harkins wrote: Stas Bekman wrote: I think the idea was to have a special thread running whose only purpose is monitoring the pool of idle interpreters. That sounds like a better solution. The drawback is that there will be two different solutions for threaded and preforked mpms, meaning harder to do transitions. I believe that we can add a Perl space hook that sets a flag that condemns an interpreter to death. The other problem, which might be harder, is to figure out how big a particular interpreter is. The current implementations of Apache::SizeLimit and GTopLimit cheat by asking the OS how big the current process is. That won't work with threads. B::Size and B::TerseSize? Since the check can be run on the idle servers that shouldn't be a problem if they are slow. On the other hand since the idea is to always re-use the recently used interpreters, I'm not sure when there will be a chance to run checks on the interpreters on the top of the pool. Need to test how fast B::Size to decide whether it's feasible to run the check during the phase when the interpreter is being returned to the pool. Also it could be that we will need various schemes for pool management and for certain servers a round-robin solution will be more memory effective if we figure out that the interpreter memory usage measuring is slow and can be done only on the idle interpreters in the pool, because in that way fat interpreters can be killed. __ 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
Re: Any way to list what compile options were used?
Eric L. Brine wrote: Is there any easy way to check which options were used to compile mod_perl. Or more specifically, is there an easy way to check which type handlers a mod_perl build allows, if it allows stacked handlers, if it allows method handlers and if it allows perl sections? Thanks. use the guide :) http://perl.apache.org/release/docs/1.0/guide/install.html#Discovering_Whether_Some_Option_Was_Configured __ 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
Re: modperl-2.0 make Error on Solaris
/users/webuser/src/modperl-2.0/xs/APR/Table/APR__Table.h:73: dereferencing
pointer to incomplete type
make[3]: *** [Table.o] Error 1
please either apply this patch or use the cvs version (which now
contains this patch) and it will work.
Index: xs/APR/Table/APR__Table.h
===
RCS file: /home/cvs/modperl-2.0/xs/APR/Table/APR__Table.h,v
retrieving revision 1.7
diff -u -r1.7 APR__Table.h
--- xs/APR/Table/APR__Table.h 12 Nov 2001 22:14:36 - 1.7
+++ xs/APR/Table/APR__Table.h 9 Jul 2002 06:51:29 -
@@ -70,7 +70,7 @@
char *filter_entry;
STRLEN len;
-tdata.filter = apr_hash_make(table-a.pool);
+tdata.filter = apr_hash_make(apr_table_elts(table)-pool);
while (MARK = SP) {
filter_entry = SvPV(*MARK, len);
__
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
Re: Trouble with DynaLoader in ActiveState bleedperl
Kent, Mr. John wrote: Greetings, modperl-2.0 installs fine on Solaris 2.7 using perl 5.6.1 with threads ON. However when I tried: For bleeding edge Perl: # (--delete to ensure a clean state) % rsync -acvz --delete --force \ rsync://ftp.linux.activestate.com/perl-current/ perl-current % cd perl-current % ./Configure -des -Dprefix=$HOME/bleedperl \ -Dusethreads -Doptimize='-g' -Dusedevel % make John, that's a question for perl5-porters --at-- perl.org. make sure to use perl-current/utils/perlbug to report the bug. BTW, ActiveState just hosts that rsync repository. __ 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
Re: nice mod_perl statistics to share
Ask Bjoern Hansen wrote: On Fri, 5 Jul 2002, Stas Bekman wrote: [...] Also you must not forget that a huge amount of back-end mod_perl servers are simply invisible to these scanners because they are running behind a proxy. So I won't be surprised if the real number is at least about twice larger. I don't understand why you think so. If the '/' url is handled by a mod_perl enable server, then mod_perl will show up in the headers, proxy server or not. Sure, there'll be some servers where you can't see that it's handled by mod_perl, but I doubt that it's all that many. $ lwp-request -e -d -S 'http://dev.perl.org/' | grep ^Server Server: Apache/1.3.26 (Unix) mod_perl/1.27 heh, that's true, shame on me :) __ 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
Re: [mod_perl2] PerlChildInitHandlers with multiple (Win32) threads
Peter Rothermel wrote: greetings, I'm looking for the documentation that describes how PerlChildInitHandlers work with multiple threads on Win32 platforms. Here's a specific question: I have the following in my httpd.conf: IfModule mpm_winnt.c ThreadsPerChild 10 MaxRequestsPerChild 0 /IfModule PerlChildInitHandler Apache::foo-genkey Will the genkey method get execute at the initialization of each thread? Apache doesn't provide such a hook yet. May be in the future. child_init is for child process init, not threads. http://perl.apache.org/release/docs/2.0/user/handlers/handlers.html#PerlChildInitHandler what are you trying to do? You should try to write your code in mpm-agnostic way if possible. so the same code can run under various mpms. __ 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
Re: [mod_perl2] PerlChildInitHandlers with multiple (Win32) threads
Peter Rothermel wrote: Stas Bekman wrote: Peter Rothermel wrote: PerlChildInitHandler Apache::foo-loadkey Will the genkey method get execute at the initialization of each thread? Apache doesn't provide such a hook yet. May be in the future. child_init is for child process init, not threads. http://perl.apache.org/release/docs/2.0/user/handlers/handlers.html#PerlChildInitHandler what are you trying to do? I'm encrypting/decrypting data within cookies that are holding session keys for authentication purposes. I decrypt the session key within the cookie data, whenever I get an http request that has a cookie in the header. The RSA keys that I use for encrytion/decryption are regenerated when the Apache server is started. My module has a load_key subroutine that I call before I do any encryption or decryption. This returns a RSA object that is initialized with a global var that hold a 2048 bit RSA key. If the global var is empty I generate a new key. The code works OK but I seem to be generating a 2048 bit key the first time that a user logs into my site. This key generation takes awhile. I would prefer generating the key when server/thread/interupter is started. I was hoping that a PerlClhildInitHandler could be used to call the gen_key subroutine to load the data into global var $private_key_string. There are a few possible approaches to this: 1. for mod_perl to provide hooks for the following events: interp_init (INIT) interp_destroy(DESTROY) so these can be run when a new interpreter is initialized after it has been cloned and when it's going to be destroyed. 2. Using the thread interpreter pool mechanism for managing other items. But it's not clear whether this interface will ever have a Perl API, because threads::shared already does that. 3. Build a pool based on threads::shared. Similar to what Doug has described in his overview: http://perl.apache.org/release/docs/2.0/user/overview/overview.html#Thread_Item_Pool_API and which is now doable in pure Perl based on threads::shared. This is an interesting vacant module, but really you can just duplicate the concepts that Doug has described in the URL above. You want to be able to add new items, remove them, pop and push from the pool. should it be called Threads::TIPool as coined by Doug? (Thread Items Pool) Using this (currently not-existing) module you can create a pool of keys at the server startup and then use them whenever you need a key at run time. This is the same concept that the threaded version of Apache::DBI is going to use, and AFAIK is vacant as well. The challenge is to make it possible to have modules like Apache::DBI work transparently under various mpms, including the preforked and perchild mpms. __ 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
nice mod_perl statistics to share
I've just updated the mod_perl with the latest stats and I'm glad to say that the results are nice, so you can show your bosses that they did the right choice (or should) ;) This is the netcraft.com: http://perl.apache.org/release/outstanding/stats/netcraft.html and this is www.securityspace.com http://www.securityspace.com/s_survey/data/man.200206/apachemods.html?mod=cGVybA== at this rate: http://www.securityspace.com/s_survey/data/man.200206/apachemods.html we are going to catch up with php quickly :) now where are the world domination T-Shirts? __ 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
Re: nice mod_perl statistics to share
Michael A Nachbaur wrote: On Fri, 05 Jul 2002 01:18:46 +0800 Stas Bekman wrote: I've just updated the mod_perl with the latest stats and I'm glad to say that the results are nice, so you can show your bosses that they did the right choice (or should) ;) Any ideas on what caused such a huge jump in usage? Besides the fact that mod_perl is awesome, of course... Sorry this info is under NDA ;) Let's see... in January 2002 the mod_perl cookbook[1] was published and since then the bar just keeps on going up. It must be Geoff, Randy and Paul's fault. Also you must not forget that a huge amount of back-end mod_perl servers are simply invisible to these scanners because they are running behind a proxy. So I won't be surprised if the real number is at least about twice larger. [1] http://www.modperlcookbook.org/ __ 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
Re: mod_perl 1.99 on Win2k with Apache2
Alessandro Forghieri wrote: Greetings. Nigel Peck wrote: Thanks for the help. When did I reply to you privately? This was just to reiterate for everybody to keep the threads on the list. Since many times those who respond to the questions, suffer afterwards because people decide that the person answering the question, is a free help desk that you can ask about anything, not talking about [...] Stas, as one that has been guilty of the same offence, let me point out that 99.9% of the time, seemingly private responses emerge from the list manager's policy of not munging the Reply-to: header - so the poor schmuck (me) hits reply and fires off a private reply to the poster. I know all about Reply-to: munging considered harmful and attending flame wars and I do not wish to delve into the relative pros and cons of the diveded camps (I'll just say that the lists I administer do the munging - period). What I wish to do is pointing out that - on non-munging lists - most standard clients require a conscious decision if they want to reply to the list, despite the fact that this would be the actual intention most of the times (so it makes for a poor interface). People stuck - like me - in Outlook-land have it even worse than most. I'm +1 on using a preset 'Reply-to:' header. httpd-dev seems to use it solely for the reason you describe. I'm all for helping people to reply back to the list. Ask, can we please have this header set? -- __ 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
Re: IPC::Open2 under mod_perl in Mac OS X
John Siracusa wrote: On 6/30/02 2:06 AM, Stas Bekman wrote: John Siracusa wrote: (I'm not sure if this is a mod_perl thing of a Mac OS X bug, so I'm posting it to both lists. Redirect follow-ups as appropriate.) open2() doesn't seem to work for me when running under mod_perl in Mac OS X. It's not a bug in MacOSX, it simply doesn't work with mod_perl. I can't post a direct example now (because I don't have access to the machine from here), but I'm pretty sure I do have an example of open2() working under mod_perl in Linux--in a perl that is not compiled with sfio. That's why I thought it was a Mac OS X bug. The mod_perl guide talks about the output from system(), exec(), and open(F, | ...) not being sent to the browser, but it doesn't mention open2(). In the case of open2(), the input and output is supposed to be tied to filehandles that I supply, not connected to mod_perl's (tied?) STDOUT that eventually goes to the browser. So could you clarify why open2() is not expected to work under mod_perl, and why it seems to work for me in Linux? (I'll post the working Linux example once I can confirm it on Monday.) I should have said that your example doesn't work on linux with mod_perl with sfio-enabled perl, since I've tried it and it didn't work. That's why I've assumed that it's not MacOSX problem. I really didn't have a chance to investigate why it doesn't work. I've just tried other alternatives which worked so I've posted them, since I thought that it was important to you to have a working solution. Feel free to debug the whole thing and post the details of what exactly doesn't work and if possible how to fix that. __ 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
Re: Need Porting Sanity Check
Jeff Crist wrote: Excuse my typos, I just wanted to clarify I added 'use strict;' not 'use stricts;' to my code along with the -w operator (#!/usr/bin/perl -w) and I'm not seeing all the errors in my logs. Because probably your code was clean in first place. Good for you. BTW, PerlWarn On in httpd.conf is an easier way to enable warnings everywhere. __ 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
Re: Storing and Serving Upload Images
Richard Clarke wrote: List, I find the following situation one which arises many times for me when creating modperl applications for people. However, I always find myself thinking there is a better way to do it. I wondered if the list would like to share their thoughts on the best way. It concerns storing and serving images/media uploaded by users of the webpage. An example could be a website letting you set up your own shops to sell products. The shop maker may allow you to upload preview images of products. Assuming the product data is stored in a database, I personally wouldnt store the binary image in the databas (assuming mysql here). A solution springing to mind is to store a hash/id in the database and have a common directory (/htdocs/_previews/) which holds the pictures named after that hash/id. That way, either the modperl application can auto create the link using src=/htdocs/_previews/imageid.jpg or a lightweight handler can be used. For example /getimage?id=asdf09sd8fsa could then rewrite the uri to the real location or perform a content subrequest and let apache serve the image that way. Of course there are many solutions, but I'm wondering. Is there a best one? Any thoughts appreciated. I realise that the same situation might occur using vanilla cgi, but mod_perl provides unique ways of solving the problem, hence I post to this list. I doubt this has anything to do specifically with mod_perl , since you are talking about storage/retrieval techniques, it'll work the same for any other technology out there. Though it's an interesting topic. A *good* filesystem can serve well as database, though you should be aware of the issue with how many files you store in each directory: the more files you put into one directory the slower the access time. Modern filesystems (definitely don't use FAT based fs) implement internal hashing of file names, but you've to check the filesystem that you use for its limits. The retrieval speed significantly slows down as the search becomes linear after you pass that limit. In that case you should do your own hashing. so you map a filename 'abcdef.gif' into a/b/c/abcdef.gif (3 levels) Again how many level of hashing to use depends on how many files you plan to store and how many files you can put into each directory so the filesystem will not go to the linear lookup. Too many levels is not good since each extar sub-dir slows things down. Once you have the numbers it's easy to calculate how much levels to use Make your code transparent to the hashing function, so in the future you can easily scale and move into extra levels of hashing. Of course if you can benchmark things comparing the RDBMS' BLOB objects retrieval speed with filesystem fetch that will help to make the decision. It also depends on the caching patterns: if you have certain images being fetched frequently the kernel/filesystem will do the caching for you. Of course you can do extra caching by yourself (squid/mod_proxy/etc) but if you can get it for free from the os level it could be even better. Check also Perrin's article, but if I remember correctly it doesn't talk about this issue. http://perl.apache.org/release/docs/tutorials/apps/scale_etoys/etoys.html p.s. to hash (3 levels) you can use something like: % perl -le '$a = super_pc.gif; print join /, (split //, $a, 4)[0..2], $a' s/u/p/super_pc.gif of course you can use a more effective hashing. __ 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
Re: CGI.pm and PerlRun
Jeff wrote: I am gradually moving to mod_Perl using Apache::PerlRun instead of Apache::Registry. I am also considering switching from cgi-lib.pl to CGI.pm however I hear CGI.pm takes longer to load. Will CGI.pm automatically be cached, thereby eliminating the performance hit, by handling the scripts with Apache::PerlRun or do I have to preload the modules at server startup using PerlModule CGI; If I preload, do I have to put a PerlModule CGI; within every VirtualHost directive or just once in the httpd.conf and it will apply to all virtualhosts. And finally if I want to run CGI.pm in CGI-LIB compatibility mode, do I have to use a startup file instead or can I say: PerlModule CGI qw(:cgi-lib); I'm guessing I have to put it in a startup file?? Jeff, you will find answers to 99% of your questions here: http://perl.apache.org/release/docs/1.0/guide/index.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
Re: IPC::Open2 under mod_perl in Mac OS X
John Siracusa wrote:
(I'm not sure if this is a mod_perl thing of a Mac OS X bug, so I'm posting
it to both lists. Redirect follow-ups as appropriate.)
open2() doesn't seem to work for me when running under mod_perl in Mac OS X.
It's not a bug in MacOSX, it simply doesn't work with mod_perl. the
piped program ('upcase' in your example) never sees any input. There are
at least two working alternatives:
1) use IPC::Run:
#!/usr/bin/perl
use strict;
use CGI qw(:standard);
use IPC::Run qw(start finish) ;
local $ENV{PATH};
print header();
my @cmd = qw(/tmp/upcase) ;
my $h = start \@cmd,
'pipe', \*IN,
'pipe', \*OUT,
'2pipe', \*ERR
or die @cmd returned $? ;
print IN Perl::Run and Barrie rule!;
close IN;
print OUT, ERR;
finish $h ;
the upcase program without any change:
#!/usr/bin/perl
$buf .= $_ while(STDIN);
print uc $buf;
2) use Apache::SubProcess:
use Apache::SubProcess ();
my $r = shift;
$r-send_http_header('text/plain');
use vars qw($input);
$input = Apache::SubProcess rules too!;
my($out, $in, $err) = $r-spawn_child(\upcase);
print $out $input;
$r-send_fd($in);
sub upcase {
my $r = shift;
$r-subprocess_env(CONTENT_LENGTH = length $input);
$r-filename(/tmp/upcase);
$r-call_exec;
}
notice that the upcase script will be different from yours in this case,
it looks like:
#!/usr/bin/perl
read STDIN, $buf, $ENV{CONTENT_LENGTH};
print uc $buf;
As this module lacks any docs, you can find them here:
http://perl.apache.org/release/docs/1.0/guide/modules.html#Apache__SubProcess
__
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
Re: Apache::compat was Apache::DBI with mod_perl 2.0
Zac Morris wrote: Ok, I went and installed Apache from CVS this time, but it looks like that installed 2.0.40-dev and I'm still getting errors during make test of mod_perl 2. Does it have to be 2.0.39 specifically to compile? Yes, to compile 1.99_04 Sorry if I'm just not getting it... It's easy: * httpd is changing all the time * Perl is changing too * mod_perl uses both APIs and therefore depends on the above two in order to give you a version where mod_perl uses the right APIs from httpd and Perl, we say the versions that you've to use. Now if you go for the cvs versions, chances are that we didn't have a chance to update mod_perl to the latest cvs changes in httpd, perl or both. And this is the case that you hit. get 5.8.0-RC2 and 2.0.39 and then 1.99_04 will compile and pass all tests 100%. __ 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
Re: mod_perl 1.99 on Win2k with Apache2
Nigel Peck wrote: Would someone please tell me where I can find instructions for installing the above? http://perl.apache.org/release/docs/2.0/os/win32/index.html Nigel, remember that you should reply back to the list if you have any further questions. Do *not* reply to me in private!!! __ 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
Re: Apache::compat was Apache::DBI with mod_perl 2.0
Zac Morris wrote: Ok, I understand. Maybe some kind of message/logic in the make to tell you that you have to have specifically x, y, z. Because I honestly DID hear you say x, y, z but my brain assumed x+, y+, z+ I've updated the README file, which now states what you need. All the troubles will go away, after perl 5.8.0 (RSN) and Apache 2.0 (ASAP) will freeze their APIs and be released. __ 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
Re: Apache::compat was Apache::DBI with mod_perl 2.0
Zac Morris wrote: Ok, still getting the same errors during make test. One of the first lines of the perl Makefile.PL --blahblah shows: Configuring Apache/2.0.39 mod_perl/1.99_04 Perl/v5.8.0 Does this mean that the make install I did on the Perl/v5.8.0_RC2 didn't take? may be you didn't install it after the build? I suggest installing everything into a new location so there will be no doubts. Just to test. just write a script that does all the work so you don't have to waste time. you can ignore the 'make test' in the perl source which is very long (assuming that it works for you) When I perl --version should it show me 5.8.0 RC2? nope. it shows 5.8.0 __ 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
Re: mode_perl and Apache 2.0
Praveen Ray wrote: Hi All Which version of mod_perl runs on latest Apachec 2.0.39 version? When I tried building mod_perl 1.27 with Apachec 2.0.39 , it gave me an error saying it needs Apache 1.3.0. That's correct. Does it mean we cannot currently run mod_perl on Apache 2.0? You run mod_perl 1.27 with Apache 1.3.x (1.3.26 the latest) You run mod_perl 1.99_04 with Apache 2.0.39. But this mod_perl is not ready for production. I need to upgrade to Apache 2.0 in order to get the latest security patches. No, you don't. You need 1.3.26. See http://httpd.apache.org/ [!!!Any follow-ups on this reply must go back to the list!!!] __ 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
Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote: Ok, still no luck. Every dependancy has more dependancies all of which go back and back to mod_perl 1 stuff already being in place My question is, can I download the Apache 1.3 source (don't make it), then run the mod_perl 1 build to get all the pm files in place, then rebuild my mod_perl 2 (against my installed Apache 2 source). Sorry Zac, my diagnosis and patch were wrong. mod_perl 2.0's compat layer doesn't require mod_perl 1.0 to be installed, sorry for confusing people. Apache::Module *is* in 2.0. But for some reason it didn't work for you. So let's try to investigate why. It seems to me that you have Apache::Module for 1.0 installed and it gets loaded instead of 2.0's version. Can you list all Apache/Module found on your machine (pm, so, etc)? locate Apache/Module I'm certain that if you install mod_perl 2.0 into Apache2/ dirs (even though you don't have mod_perl 1.0 installed) this problem will go away. But I'd still like to figure out what kind of collission you have now. Also, we mentioned the whole Bundle::Apache, will there be one of those for Apache 2 and will it contain all the mod_perl 1 AND mod_perl 2 stuff to allow running in Compat? no, it'll contain only stuff needed for 2.0, which may include modules that work for both mod_perls, but definitely not mod_perl 1.0. Again I apologize for my mistake. __ 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
Re: mod-perl 2.0 and CGI.pm
Kent, Mr. John wrote: Greetings, Tried to run some benchmarking tests on a cgi generated web page comparing a light and heavy server. ab worked fine when testing the script run by the Apache 2.0.39 light server ab reported failure when testing the same script running on Apache 2.0.40-dev with mod-perl 1.99 any luck with ab from 2.0.40? I've just done some testing with CGI.pm (it was printing the whole set of xml headers) and it seems to be fine (with ab from 1.3 and 2.0). Care to send a *short* script that represents the problem? __ 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
Re: ANNOUNCE: mod_perl-1.99_04
So that this question won't be repeated again and again: If you build with perl 5.8.0, you need perl-5.8.0-RC2 in order to build mod_perl-1.99_04. If you use 5.6.(0|1), please disregard this note. __ 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
Re: Apache vulnerability: update of uwinnipeg win32 packages planned?
Alessandro Forghieri wrote: but I wasn't planning on making a new one of those until perl-5.8 is officially released. Any idea on when that may happen? My wild guess is on July 24, 2002. __ 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
Re: getting node values from XML::Parser
[EMAIL PROTECTED] wrote: ok, it's 1am, time to ask. I am able to parse thru XML (using XML::Parser, Expat) to retrieve the element I am interested in with: my $line= $parser-current_line; $data =~ s/\n/n\t/g; but how to get the element value?? thanks for advice, md is it just me or others think too that someone has started to advertise the address of the mod_perl mailing list as the place Ask about anything, any time, we know the answers. Doh! I suggest renaming the address of the modperl list to: [EMAIL PROTECTED] [hope that spamming engines will pick that one and spread the word around fast] __ 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
Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote: Yeah, so I've tried these suggestions: use Apache2(); use Apache::compat; and I'm still getting the errors: Undefined subroutine Apache::Module::loaded called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/compat.pm line 95. Compilation failed in require at ./db_connect_test.pm line 38. BEGIN failed--compilation aborted at ./db_connect_test.pm line 38. Apache::Module is not a part of the mod_perl 1.0 core, unfortunately you have to install it to get this thing working. We will see if there is a better solution for this kludge. I think this boils down to something Per said earlier, I've never installed mod_perl1 only mod_perl2 on an apache 2 server... you cannot install mod_perl 1.0 with apache 2 server. You probably mean within the same perl libs install, since you can have both versions reside under the same perl installation. As I understand it the use Apache::compat just allows your script to utilize the mod_perl1 modules correct? mod_perl 1.0's third party modules, yes. -- __ 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
