Re: [RFC] Apache::LDAP
James G Smith wrote: Per Einar Ellefsen <[EMAIL PROTECTED]> wrote: Hi James, At 02:32 02.12.2002, James G Smith wrote: ( Actually, the name is chosen to `rhyme' with Apache::DBI. There are no dependencies on Apache or mod_perl. ) If there is no link with Apache::DBI, I suggest that you choose a more appropriate namespace, like Persistent::LDAP Unfortunately, that's already taken. The module on CPAN implements persistent objects with an LDAP backend (if I read the docs right). Net::LDAP::Persistent is not taken and seems like a good choice to me. --- re: modules discussion lists. Are you sure you are talking about the right list? I thought that module-authors at perl.org is the one for discussing general perl modules. Whereas modules at perl.org is for CPAN namespace registration submission. I've found the latter to be much more helpful, with Tim Bunce usually taking the pains of proposing better namespaces. So whenever I propose a new module I go first to module-authors and if nothing happens I take it to modules, which happens in any case, because I want my modules to be registered. p.s. those module authors who want their modules to be registered (it's not enough to upload the module on CPAN), login into your PAUSE account and go to the registration section. If you have further questions module-authors at perl.org is the place to ask 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: [mp1] Still can not get working DSO configuration on Tru64
Marcin Kasperski wrote: In short: I tried different compilation methods with two possible outcomes: a) apache and modperl compile succesfully but I get coredump while the application is starting (in all cases SEGVs, in some cases core's confused the debugger, in other I managed to notice __at_fork in backtrace) b) everything seem to compile succesfully but I get dlopen: /tools/apache/libexec/mod_perl.so: symbol "PL_perl_destruct_level" unresolved while the application is starting Maybe it is worth noting, that I happened to get b) also when I compiled perl with shared perl library (in contrary to suggestion found in modperl docs that building perl with shared library should help). 2 years ago, there was a similar struggle as you can see from this thread: http://marc.theaimsgroup.com/?t=9744223061&r=1&w=2 May be those participants are still using True64 and can give you some hints? ______ 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 2?
3. If you have different sites (presumably owned by different people) on your server, all the backend servers can execute with different userids so that the backend server of one site doesn't have to be able to read the files of another site. And, everyone can change their own server configuration. We know that Apache 2 confers benefit #1 without needing a separate frontend and backend. Benefit #2 seems to be planned, but isn't here yet. ...What about benefit #3? #3: --with-mpm=perchild which is a work in progress http://httpd.apache.org/docs-2.0/mod/perchild.html notice the new AssignUserID and ChildPerUserID directives which now can set different uid/gid for each group of processes/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
Fwd: Red Hat's use of mod_perl
Thanks Chip, great info! please keep those coming, we will update the site once we have several of these new additions. The original request is here: http://use.perl.org/articles/02/11/29/1837238.shtml?tid=11 Original Message Subject: Red Hat's use of mod_perl Date: 29 Nov 2002 23:30:24 -0500 From: Chip Turner <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Hey Stas, Just saw your request on use.perl.org. Red Hat's main website, www.redhat.com, is a mod_perl site (mainly Apache::ASP). Also, the Red Hat Network's website, rhn.redhat.com, is pure mod_perl, using a custom templating system (which I'll release one day, as soon as I find time..). It's actually a fairly complicated use of mod_perl for a web application, totalling around 60k likes of perl. Hope this is useful, Chip -- Chip Turner [EMAIL PROTECTED] Red Hat, Inc. -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp 2.0] can not compile mp 1.99_07
Dipl.-Inform. Kai Hofmann wrote: > I tried to compile 1.99_07 - but there is a definition of > IoTYPE_WRONLY and IoTYPE_REONLY within the file apr_perlio.c > which can not be resolved unter SuSE Linux 7.2 with Apache 2.0.43 > I greped all includes without any success where these things will be > defined - any hints? > Last time I compiles 1.99_03 successfully. Thanks for the report Kai. Fixed in the current cvs. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
[patch] Apache::DB now works with 5.8.0+
To all those having problems with Apache::DB and perl 5.8.0+ (CC'ing all
those who have complained recently).
Try this patch:
--- Apache-DB-0.06/DB.pm.old 1999-10-12 07:50:33.0 +0800
+++ Apache-DB-0.06/DB.pm 2002-11-29 18:03:47.0 +0800
@@ -14,6 +14,7 @@
$Apache::Registry::MarkLine = 0;
sub init {
+*DB::DB = sub {} unless DB->can("DB"); # temp definition for 5.8.0+
if(init_debugger()) {
warn "[notice] Apache::DB initialized in child $$\n";
}
______
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: default Content-Length calculation has been removed in 2.0 (wasRe: mod_perl 2.x vs. mod_perl 1.x benchmarks)
Well, it's been getting *WAY* OT - more geared for dev@httpd if anywhere, but I'm sure they've argued this out already :-) My initial ideas all counted on the fact that each handler/filter would have a way of getting its own per-request thread... On the opposite, IMHO this is very ON topic, since that's the core of the 2.0. there is a talk about async I/O mpms for 3.0, or later 2.x This sounds like our "many buckets with firemen" scenario - but, again, it only really becomes useful if the handlers/filters have their own thread running space. That's the real pipeline. But it'll be only useful if you have many CPUs. I remember reading somewhere, that on a single CPU sequential processing might be faster rather than pseudo-parallel, because of the context-switch overhead. Though admittedly it's much smaller with threads, but depends on the implementation. Now, nothing prevents you from developing your own mpm right now or at any time latter that will do what you want. It's actually much easier that it seems to be because a big chunk of functionality is abstacted away. So it's not like writing an Apache server from scratch. I admit that I haven't written my own mpm yet and that's the impression that I have from reading posts at httpd-dev. But the conclusion I'd draw from this, getting back to the original question, is that under Apache 2, it's *still* worth doing a frontend/backend setup where the frontend buffers all the backend data. Even if we *did* write the buffer filter, if the whole pipeline is stuck in one thread, then we're not freeing up the resources when the heavy handler/filter is done, so slow clients will still clog server resources. Yes and no. Remember that our perl interpreters live in a separate pool of threads, so if we can release them asap, they can go and serve more requests, while the filters do whatever they do. Since the perl interpreters don't reside on the same thread that serves the connection. Though you are correct that the response handler won't be released until the filters will be done. So we need to think of some trickery to release the response handler earlier. The frontend/backend solution takes care of this, because here, we're creating our own 2-threaded pipeline: the important thing being that the frontend should either have a buffer filter, or better yet, a "constant flush + buffer" filter to get the data from the backend straight to the client, while buffering additional data if needed. Does this make sense to you? Sure, there is nothing wrong with front/end backend setup, it just makes things a bit more complicated to setup and maintain. So if we can provide an alternative solution that requires only one server, that would be cool. That's said let's worry first to get the core things working first and if you want to play with optimizations please go ahead and hack away :) __ 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
Stas Bekman wrote: Harry Danilevsky wrote: I did send the patch to Matt couple of days ago, but haven't heard back yet. Matt is on vacation I suppose I can also brace myslef, add namespaces, and clean up my own code. That's a good idea. As for the versioning, if this patch could be useful in both mod_perl 1.* and 2.0, can it be applied to both distributions? I don't quite understand why installing Apache::Reload from CPAN will cause mod_perl2.0 to be installed, but I'll try to think some more about it. Because Apache::Reload is distributed on CPAN and is not a part of mod_perl 1.0. And a genetically modified version is included in mod_perl 2.0. The right solution is probably to make Apache::Reload a part of mod_perl 1.0 as well and kill the CPAN version, or simply have a higher number on it. So people won't need to install it manually. I've committed your patch to the Apache::Reload version distributed with mod_perl 2.0 (plus documented the new feature). I've no control over the mod_perl 1.0 version maintained by Matt. Thanks for the patch Harry. ______ 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: [mp1] callback called exit (many times)
Marcin Kasperski wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Marcin Kasperski wrote:
Recently I happened to get the error log flooded with the message
callback called exit
(repeated a couple of million times, probably by one process or a few
processes).
This was some side-effect of the lack of memory
(...)
Hope that the following somewhat helps:
http://perl.apache.org/search/swish.cgi?query=callback+called+exit&sbm=SecD&submit=search
Thank you for the pointer.
Am I right deducing, that I should attempt recompiling perl with
-DEMERGENCY_SBRK?
Try to, but this doesn't solve the original problem. You still have to
try to narrow down the code that causes the problem. Using ab or a
similar load tester might help to stress test.
Using tools to prevent situations when the server runs out of memory is
very important. See the online docs for more info. Using these tools
should probably solve the problem altogether, without using any special
compilation options.
The perl I use describes itself as below so probably this option is
not turned on:
Hmm, it's been a long time since we've last revisited this issue. The
doc says that PERL_EMERGENCY_SBRK it's supposed to be on, but a quick
test on several of my builds shows that it's not true:
#!/usr/bin/perl
use Inline C;
print "PERL_EMERGENCY_SBRK is @{[ mytest() ? '' : 'not']} defined\n";
__END__
__C__
int mytest() {
#ifdef PERL_EMERGENCY_SBRK
return 1;
#else
return 0;
#endif
}
~/perl/5.8.0-ithread/bin/perl test.pl
PERL_EMERGENCY_SBRK is not defined
of course there is the source code, but Inline is nice :)
______
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: [mp1] callback called exit (many times)
Marcin Kasperski wrote: Recently I happened to get the error log flooded with the message callback called exit (repeated a couple of million times, probably by one process or a few processes). This was some side-effect of the lack of memory (earlier in the logs I found messages about allocation failures), which in turn was caused by some non-apache process allocating too much. Nevertheless, I am trying to find what happened to my apache/modperl process (processess?). After all, aborting some processes due to lack of memory is ok, but filling the whole disk with error log is not. It is possible that the problem is not caused by the modperl itself (for instance some of additional modules we implemented in both C and perl could go wild). But trying to understand the problem I would like to ask the following questions: a) Have anyone anywhere observed similar behaviour? b) When is the message 'callback called exit' printed - and can it be disabled? c) Do you have any idea of what should I pay attention to? Hope that the following somewhat helps: http://perl.apache.org/search/swish.cgi?query=callback+called+exit&sbm=SecD&submit=search ______ 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 problems making mod_perl run: Apache/2.0.43 (Unix) mod_perl/1.99_07-devPerl/v5.8.0
Juan Julian Merelo Guervos wrote:
Hi,
Well, looks like I've managed to make this server run (thanks for your
help), and looks like, in this case, mod_cgi is working (unlike the one
shipped with RH 8.0). Now I'm trying to make HTML::Mason work with this
configuration. I have downloaded HTML::Mason 1.15, and force-compiled
it. This one requires libapreq, which I haven't been able to compile,
since it requires Apache::MyConfig . That's supposed to be in the old
version of mod_perl, right? So, the only way to have HTML::Mason working
is to have both things working at the same time? Any other option? Has
anybody made HTML::Mason work with this prerrelease of mod_perl?
I did a quick stub on porting Apache::MyConfig, it's incomplete so
please post any fixes (which should be pretty easy to figure out) for
those keys that weren't set yet. So here is the patch.
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.71
diff -u -r1.71 compat.pm
--- lib/Apache/compat.pm 23 Nov 2002 22:35:06 - 1.71
+++ lib/Apache/compat.pm 28 Nov 2002 16:52:49 -
@@ -509,5 +509,80 @@
APR::Table::make($r->pool, $nelts);
}
+package Apache::MyConfig;
+
+use Apache::Build ();
+
+use constant WIN32 => Apache::Build::WIN32;
+
+our %Setup;
+
+my $build = Apache::Build->new();
+
+my $XXX = "Need to figure out";
+my $LEGACY = '';
+
+%Setup = (
+APACHE_SRC => $build->MP_AP_PREFIX, # can be not source
+SSL_BASE => $LEGACY,
+APXS => $build->apxs,
+PERL_USELARGEFILES => $XXX, # XXX
+PERL_TRACE => $build->MP_TRACE,
+PERL_DEBUG => $build->MP_debug,
+APACI_ARGS => $LEGACY,
+APACHE_PREFIX => $build->MP_AP_PREFIX,
+DO_HTTPD => 1, # always DO_HTTPD
+NO_HTTPD => 0, # always DO_HTTPD
+PREP_HTTPD => 0, # always DO_HTTPD
+USE_APACI => 0, # no more
+APACHE_HEADER_INSTALL => 1, #
+PERL_STATIC_EXTS => $XXX,
+PERL_SSI => 0, # legacy
+USE_APXS => $XXX, # only for non-win?
+);
+
+my @callback_hooks = qw{
+PERL_DISPATCH
+PERL_CHILD_INIT
+PERL_CHILD_EXIT
+PERL_POST_READ_REQUEST
+PERL_TRANS
+PERL_HEADER_PARSER
+PERL_ACCESS
+PERL_AUTHEN PERL_AUTHZ
+PERL_TYPE
+PERL_FIXUP
+PERL_HANDLER
+PERL_LOG
+PERL_INIT
+PERL_CLEANUP
+PERL_RESTART
+PERL_STACKED_HANDLERS
+PERL_METHOD_HANDLERS
+PERL_DIRECTIVE_HANDLERS
+PERL_TABLE_API
+PERL_LOG_API
+PERL_URI_API
+PERL_UTIL_API
+PERL_FILE_API
+PERL_CONNECTION_API
+PERL_SERVER_API
+PERL_SECTIONS
+};
+
+# we have all the APIs available, just need to load their modules
+$Setup{$_} = 1 for @callback_hooks;
+
+if (WIN32) {
+$Setup{APACHE_INC} = $build->{APXS_INCLUDEDIR};
+$Setup{APACHE_LIB} = $XXX;
+$Setup{MODPERL_INC} = $build->{MODPERL_INC};
+$Setup{MODPERL_LIB} = $XXX; # win32 lib?
+}
+
+#need this alias for Apache::src backwards compat
+$Setup{Apache_Src} = $Setup{APACHE_SRC};
+
+
1;
__END__
__
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 and @INC
Igor Vylusko wrote: in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). SB> It's not easy with mod_perl 1.0. The manpage is talking about changing SB> @INC globally for the whole server. I usually do that with 'use lib' in SB> startup.pl. I define PerlSetEnv PERL5LIB globaly for the whole server but PERL5LIB was stripped out from @INC anyway on enabling PerlInitHandler Apache::Reload in _any_ vhost. I am using PerlSetEnv PERL5LIB per vhost basis and it works fine for me without Apache::Reload. I can't reproduce what you see with Apache::Reload and I don't see anything in the code that mangles @INC. Though what I do see, is that if you define PERL5LIB outside a VirtualHost, it overrides any PERL5LIB defined inside all VirtualHosts, no matter if you use Apache::Reload or not. I don't remember if that's how it should be or whether it's a bug. Those who use vhosts can probably help rectify the issue here. ______ 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: default Content-Length calculation has been removed in 2.0 (wasRe: mod_perl 2.x vs. mod_perl 1.x benchmarks)
[Issac's view snipped] Rather than commenting on your view Issac, please allow me to try again to explain how I think it works, hopefully more clear this time: Let's forget for a moment about buckets inside bridades, and call the brigades themselves "entities" that are passed along. Now think of a realworld fireman water bucket brigade, everybody passes a bucket (entity) and usually there are several buckets (entities) moving at the same time. Now let's imagine that the first man in the brigade picks a new bucket only when the last man has poured its bucket out. So at any given moment there is only one bucket (entity) moving along the brigade. This is exactly the situation with httpd. In the current httpd filtering model one entity is moving along the filters stack and no new entity will enter the stack, before the one on the stack will leave it (go to the client if we are talking about output filters). I didn't want to use the httpd buckets and brigades in this example, because they make my comparison confusing. In the real world there is one brigade and many buckets. In httpd, there are many bridages that are moving along the stack of filters (and each brigade have one or more buckets, which are irrelevant to this particular discussion). Hope this clearifies the picture. The conclusion: If the filter stack is busy processing some data and the response handler hasn't finished sending the data, it'll block waiting for the filter stack to return and only then hand over the next chunk of data. At least that's how it appears to the filters. Now if you want to play with it, it should be a trivial thing to do. Just take some response handler that generates a lot of data in a loop and prints some logs to STDERR on each iteration, then insert a filter that passes the brigades unmodified (like MyApache::FilterSnoop does) but has a 'sleep 3' statement. I expect that the response handler will block on each sleep. I hope that my understanding was correct :) Also allow me to suggest that reading the following section: http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter and trying the MyApache::FilterSnoop module at work should clearify a lot. ______ 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: flush problem
Udlei Nattis wrote:
$r->rflush() doesnt work too
you have other idea?
I believe this was a bug in httpd, where the content was buffered up to
calculate the Content-Length header. I've tested it with the cvs version
of httpd and $|=1 sends the unbuffered output as with your original example:
use strict;
$| = 1;
my ($i,$r);
$r = shift;
$r->content_type('text/html');
while ($i < 10) {
$r->printf($i."\n");
$r->printf("\0");
$i++;
sleep 1;
}
---
$r->rflush() is indeed not working yet.
______
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: PATCH Apache::Status.pm
Dan Sully wrote:
This makes the syntax tree dump work for Apache::Status
--- lib/Apache/Status.pm.orig Tue May 28 09:33:28 2002
+++ lib/Apache/Status.pm Tue Sep 24 12:09:56 2002
@@ -345,6 +345,7 @@
sub noh_b_terse {
my $r = shift;
+return unless eval { require B::Terse };
Thanks Dan. Committed this and added two more similar fixes which solve
the same problem in two other functions in that module.
__
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: Compilation problems with mod_perl
Stas Bekman wrote: Benny Jensen wrote: Hello, I'm trying to compile mod_perl for apache2. But i got a error message that i dont know how to solve. The following message is what i get: /LD_RUN_PATH="" cc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status / APR.so exist in following map: //usr/local/lib/perl/5.8.0/Apache2/auto/APR/APR.so/ If anyone could help me to solve it it's looking for libapr, not APR. You must have messed up the apache build step or missed it completely and don't have apache built yet. Review the installation steps at: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_Installing_Prerequisites That was actually a broken build after the apr project has changed the way it names the libraries. So please disregard my previous reply and get the latest cvs, it should work 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
default Content-Length calculation has been removed in 2.0 (was Re:mod_perl 2.x vs. mod_perl 1.x benchmarks)
Frank Wiles wrote: .--[ Ask Bjoern Hansen wrote (2002/09/19 at 01:47:39) ]-- | | On Wed, 18 Sep 2002, Josh Chamas wrote: | | [...] | > So I run it again with ServerTokens Min, and get the same results. :) | > Still something different on the mod_perl headers, looks like mod_perl | > 2.x is setting Content-Length where it didn't use to. | | The details evade me, but I recall something about how the buckets | work in the httpd that makes httpd 2.0 always know (and set) the | Content-Length. | | There was discussion about changing it; but I don't remember the | outcome. This has been changed to do the right thing around mid-Sep I believe. Previously httpd was buffering up the output and calculating the Content-Length header before sending the HTTP headers. It doesn't do that anymore, which is a relief for us. I've discovered this just before my presentation, where I've planned to demonstrate that bad behavior using the filter snooper, but there was no need any more :) You can still inject a cl filter which will buffer the data and calculate its length e.g. to be cache friendly, if that's your intention. Actually, returning to Issac's question regarding releasing the handler early, you need a slightly modified version of the cl filter to do that. Since it's already buffering the data, you just want to do this unconditionaly. ______ 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 using a startup file
Ged Haywood wrote: On 27 Nov 2002, Jan Theofel wrote: Especially because we use SuSE Linux Enterprise Server which is a hihgly integrated system and we would loose the benefits of this system when we compile apache on our own. I don't understand that at all. Can somebody help me out here? Sure. Many (linux|other) systems nowadays rely on Apache and Perl to do the UI to the system. Therefore they sometimes (always?) patch or change these tools to do what they want them to do. And when you want to add your own things collisions might happen. Therefore if you want to keep the system intact, build your own Apache and your own Perl in a different directory. You especially want this if you are a developer that need to make sure that the product works with various versions. e.g. I have: % ls ~/perl/ 5.005_03 5.6.0 5.6.0-ithread 5.6.1 5.6.1-ithread 5.8.0 5.8.0-ithread blead blead-ithread % ls ~/httpd/ 1.3 2.0 prefork prefork-apreq threaded worker Of course you probably don't need them all, but you get the idea. the only caveat of installing your own Apache is that you can't use port 80, if the system's Apache uses it. A simple rewrite rule solves this 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: Apache 2?
Issac Goldstand wrote: - Original Message - From: "Stas Bekman" <[EMAIL PROTECTED]> . Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. This isn't just a mod_perl thing, either. This would be a generic Apache2 thing. *ANY* content should be filtered as such through a 2-tier system like this - but I thought that's what the bucket brigades did. Please correct me if I'm wrong in this picture: Response Handler > start of buckets > Filter API > End of buckets > Core Output > client it was my understanding that one of the purposes of the core-output filter was to do exactly what we want - free the backend request and filter threads once they've finished with the EOS bucket. Am I missing something? From a quick read through: server/core.c:static apr_status_t core_output_filter(ap_filter_t *f, apr_bucket_brigade *b) I don't think core_output_filter does anything to buffer up the data and release the handler. The only buffering it does is if it doesn't have *enough* bytes to send so it waits for the next brigade. In order to understand how the new model works you really have run the snooping filter and study the output. The important outcome that you gain is that filters are called in a pipeline, i.e. the response handler sends a portion of data to the first filter, which immediately passes that data to the next filter, and so on, while all previous filters that have already passed the first chunk await for the latter filters to return. That's my understanding so far, please correct me if I'm wrong. So if you want to release the handler asap, you need a filter that will buffer up the data and feed it to the remaining filters at the speed they request. It should probably be inserted just before the core_output_filter, so all the processings will be already completed by that time. Think of it as an extension to the core_output_filter which buffers things up. And the cool thing is that you can inject it only when you want it, e.g. you don't want it for non-mod_perl requests. And of course it's not mod_perl specific like you've mentioned, but I don't really know of any other producers that consume a lot of memory and therefore for which we want to minimize their number and keep them busy for real all the time. __ 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 and @INC
Igor Vylusko wrote: Hi All, in doc http://perl.apache.org/docs/2.0/api/mod_perl-2.0/Apache/Reload.html declared that when using Apache::Reload I may define additional lib in httpd.conf: PerlSetEnv PERL5LIB /home/httpd/perl/extra But when I enable PerlInitHandler Apache::Reload in config all libs defined in PERL5LIB are gone away from @INC. I have Apache 1.3.27, mod_perl 1.27, Apache::Reload 0.07, perl 5.8.0 on RH7.2 and try PerlSetEnv PERL5LIB in main config section as well as in VirtualHost sections. I have bulk of VirtualHosts and would like make @INC different for each one(i.e. not use lib ... in startup.pl). It's not easy with mod_perl 1.0. The manpage is talking about changing @INC globally for the whole server. I usually do that with 'use lib' in startup.pl. Has anybody run across this problem? If sowhat is my solution? There are several solutions, none of which is very helpful in production, since they either slow things down or may cause collisions when modules with the same names are loaded, see: http://perl.apache.org/docs/1.0/guide/config.html#Is_There_a_Way_to_Modify__INC_on_a_Per_Virtual_Host_or_Per_Location_Basis_ _________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: OT: localtime can't handle epochs less than 0 ???
simran wrote: Off Topic General Perl Question --- Please don't do that. And for others, please don't reply to this kind of questions even though you know the answer, and thus encouraging these questions. Let's keep focused on mod_perl here. On another note, can anyone points me to a general perl questions list that they would recommend (not too much traffic and medium to expert level?) Certainly! http://lists.perl.org/ provides a gazillion of perl related lists and newsgroups for you choose from. _________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: make test failed when installing mod_perl 2.0 on Linux
Your attention please: [***] [*** ***] [*** please send the followups back to the list! ***] [*** ***] [***] Thank you! Now to the solutions: Dawn Sun wrote: I've used this patch>> Index: t/hooks/TestHooks/init.pm === RCS file: /home/cvs/modperl-2.0/t/hooks/TestHooks/init.pm,v retrieving revision 1.3 diff -u -r1.3 init.pm --- t/hooks/TestHooks/init.pm 18 May 2002 02:02:32 - 1.3 +++ t/hooks/TestHooks/init.pm 26 Nov 2002 12:20:03 - @@ -56,6 +56,7 @@ __DATA__ PerlInitHandler TestHooks::init::second +PerlModule TestHooks::init PerlInitHandler TestHooks::init::first PerlResponseHandler TestHooks::init But "make test" failed again. This time, the error changed from the "Can't locate TestHooks/init/first.pm in @INC... " to "Can't locate TestHooks/trans.pm in @INC...". Other errors remain the same. Good, so probably adding PerlModule TestHook::trans in a similar way (inside of t/hooks/TestHooks/trans.pm) should solve that problem too. Though it should have resolved the handlers automatically. You need to enable PERL_TRACE (see the online docs) and post the trace so we can see why these don't get resolved. ______ 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 2?
Philip Mak wrote: These days, Apache 2 has become the default version of Apache. On my site, I run a front end Apache and a back end Apache. Front end: Apache 1.x, has mod_accel module which is like mod_proxy, but downloads all the data from the backend ASAP and frees it up immediately, so that a slow modem doesn't tie up the backend Back end: Apache 1.x with mod_perl Here's my question: Is it worth upgrading to Apache 2.x for either the front end or back end? And does Apache 2.x's mod_proxy free up the backend ASAP now? Theoretically with mod_perl 2.0 with Apache2.0 threaded mpms architecture the need for the front-end/back-end solution has gone away, because now you can have a few threads running Perl interpreters and many other threads which don't run Perl interpreters. So the front-end and the back-end can now co-exist on the same server. Practically we still need to work out the details. Since if your mod_perl handler sends the data to a thread which runs a filter that send the data to a client (and doesn't need perl) it'll still block on the network transfer, which will block the response handler sending the data. So I can imagine that we will need a special filter that buffers the data, immediately releasing the perl handler and then slowly feeding it to the the client. The prototype can be written in perl and then probably better ported to C. You can use the MyApache::FilterSnoop (http://perl.apache.org/docs/2.0/user/handlers/filters.html#All_in_One_Filter) to trace the data propogation through filters. Of course first you need to understand the 2.0 architecture, which is discussed in details at http://perl.apache.org/docs/2.0/user/index.html (Part IV: mod_perl Handlers). As this is a new documentation please help to improve it. Especially if you have more interesting examples, than the ones I've come up with. ______ 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 2?
Philip Mak wrote: On Tue, Nov 26, 2002 at 03:11:47PM -0800, Grant Cooper wrote: Is there any documention of a HOWTO or a tutorial about a lightweight front-end proxy that loads the data from the mod_perl I wrote a guide a while back on how to install mod_accel and mod_deflate with Apache. It's for Apache 1.3.x; I don't know if it will work with Apache 2.x. http://www.aaanime.net/pmak/apache/mod_accel/ and of course your perl.apache.org docs: http://perl.apache.org/docs/1.0/guide/strategy.html http://perl.apache.org/docs/1.0/guide/scenario.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: 2.0 estimated release date?
Jim Martinez wrote: Full of ideas from apachecon and Vegas (cha ching!), I wonder when mod perl 1.99 will become 2.0. Any guesses? Somewhere next year? Though some people are already using it in production. It all depends what functionality is needed, since the core is pretty much done, but there are many angles to polish. Of course since you are talking about the ideas from apachecon, you must be talking about the new features 2.0 provides. Both filters and protocols handlers work and they will probably require some extra tuning as more people start using them. 2.0 does need early adopters, who are willing to try things and be patient to report problems and help workout the solutions. 2.0 needs a lot of real world testing before it will released, something that no test suite can replace. __ 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: Identifying memory leaks
Charles wrote: A Linux machine running Apache/2.0.35 (Unix) mod_perl/1.99_05-dev Perl/v5.6.1 mysql 4.0.1 uses increasing "used" memory (according "/usr/bin/free"), eventually resuting in all memory being consumed. Memory usage drops somewhat after a reboot of apache and mysql, but not completely. Well, why it's possible. I doubt it does. Most likely your code causes the leakage. First of all, if you don't report the complete details about your build we can't even start helping to you. Use the proper procedure of reporting problem as described here: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems (linked from the shortcuts menu on the left of perl.apache.org so it's *easy* to find) Second, do you see the same behavior under mod_perl 1.0? If a reference does not go out of scope between sessions, that memory will not be garbage collected. I would like to test for these types of difficulties. First of all you should try and isolate the problem, so your test case is simple. Debugging a huge program can be a problem. The mod_perl guide discusses several ways to debug problems, though not all tools are available to 2.0 yet, so you better off debugging this with mod_perl 1.0 if possible. For example see: http://perl.apache.org/docs/1.0/guide/debug.html#How_can_I_find_out_if_a_mod_perl_code_has_a_memory_leak Questions: Are there tools to track total (all threads/processes) mod_perl, apache, mysql memory usage? Apache::VMonitor for mod_perl 1.0 should be of a good help. I've several obstacles that I'm trying to resolve at the httpd land and then I'll make it available for 2.0. What is the normal behavior for a module which connects (via a global) to a database in terms of mysql processes started? it's also possible that the way your wrote the code brings huge chunks of data from db into the memory and never frees them. (e.g. a closure problem http://perl.apache.org/docs/general/perl_reference/perl_reference.html). in summary, narrow down the test case if possible, hopefully without involving any rdbms code, send the complete details of your setup and we will see what can be done. ______ 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: partial page display
Jim Martinez wrote: After much thought on Nov 26 [EMAIL PROTECTED] wrote: I suspect possibly there's some massaging we can do to the header? I wonder if your thinking of the meta tag refresh : http://mydomain.com/tracking.pl> Is this a good idea? I hope so, because I'm using it. Nope, especially when you *can* control the HTTP response headers. This HTML extension is not supported by all browsers. See http://marc.theaimsgroup.com/?l=apache-modperl&m=103658812122901&w=2 Instead you should use the HTTP headers to do that. The following thread discusses this issue to death: http://marc.theaimsgroup.com/?t=10365327621&r=1&w=2 ______ 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: partial page display
[EMAIL PROTECTED] wrote:
Thanks, finally found the right combination...
{
local $| = 1;
$r->content_type('text/html');
$r->send_http_header;
print "Testing...\n";
}
Peruse the docs and they will save your time:
http://perl.apache.org/docs/1.0/guide/performance.html#Using1_Under_mod_perl_and_Better_print___Techniques_
______
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 compiling mod_perl 1.99_07 in RH 8.0
[please, post followups to the list! everybody else on the list wants to
know the answer, not only you. thanks!]
J. J. Merelo wrote:
Hi,
Looks like that corresponds to libapreq ; but I'm not too sure where to
get it. Is it included in the Apache release? Is it in apache-devel? I
have found a RPM for it, but now I'm not sure that's reliable either.
¿Any idea?
you have to install httpd-2.0, before you build mod_perl 2.0, and it
installs apr and apr-util libs. see the online docs.
Sorry I didn't mention it, but I built apache 2.0.43 under the same
upper dir, and installed it under /usr/local/apache2. The command line
for building was:
perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2
It does have the apr and apr-util libs, in the correct directory I
guess.
ls /usr/local/apache2/lib/
apr.exp libapr-0.lalibapr-0.so.0.9.2 libaprutil-0.so
aprutil.exp libapr-0.solibaprutil-0.a libaprutil-0.so.0
libapr-0.a libapr-0.so.0 libaprutil-0.lalibaprutil-0.so.0.9.2
Do I have to define another config variable or something?
Oops, they did it again. Around mid-Sept the apr project has changed the
way they name libs. None of us have had problems because we still had
the old libs with the old conventions linked instead of the new ones.
what used to be libapr.so.0.9.2, now is named libapr-0.so.0.0.2 (same
for aprutil), similar to libdb's naming convention.
So here is the patch that will get you going if you use the current cvs.
Though it won't work with older aprs. Should probably hide the
differences in the ModPerl::MM build.
Index: xs/APR/APR/Makefile.PL
===
RCS file: /home/cvs/modperl-2.0/xs/APR/APR/Makefile.PL,v
retrieving revision 1.4
diff -u -r1.4 Makefile.PL
--- xs/APR/APR/Makefile.PL 6 Apr 2002 04:42:00 - 1.4
+++ xs/APR/APR/Makefile.PL 26 Nov 2002 13:56:11 -
@@ -4,12 +4,11 @@
my $prefix = ModPerl::MM::build_config()->apxs(-q => 'PREFIX');
-my $libdir = "$prefix/lib";
-
-my @libs = map "-l$_", qw(apr aprutil);
+my @libs = map { qx{$prefix/bin/$_-config --link-ld} } qw(apr apu);
+chomp @libs;
ModPerl::MM::WriteMakefile(
'NAME'=> 'APR',
'VERSION_FROM' => 'APR.pm',
-'LIBS' => ["-L$libdir @libs"],
+'LIBS' => \@libs,
);
__
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 characters being added to a request.
=sp1%26path=ASIN/B2SUQV $test2 = $string3 . $string2 is: characters with evenhttp://www.amazon.com/exec/obidos/redirect?tag=mobygames%26creative=D12JEXH87B4VLK%26camp=2025%26link_code=sp1%26path=ASIN/B2SUQV Wierd, huh? If you look in the error log, you'll see that both test1 and test2 printed out without that funny looking character. -- __ 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 compiling mod_perl 1.99_07 in RH 8.0
J. J. Merelo wrote: Hi, This new RH 8.0 installation is resulting in a calvary. After finding that mod_cgi does not work, that the mod_perl that comes with it breaks all scripts I've got, I have decided to build the latest apache version and mod_perl from scratch. But looks like I am also bumping into problems here: when compiling it, I get this error LD_RUN_PATH="/usr/lib" gcc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/auto/APR/APR.so -L/usr/local/apache2/lib -lapr -laprutil /usr/bin/ld: cannot find -lapr Looks like that corresponds to libapreq ; but I'm not too sure where to get it. Is it included in the Apache release? Is it in apache-devel? I have found a RPM for it, but now I'm not sure that's reliable either. ¿Any idea? you have to install httpd-2.0, before you build mod_perl 2.0, and it installs apr and apr-util libs. see the online docs. ______ 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 make source_scan
Esteban Fernandez Stafford wrote: Hello, I wanted to add some functionality to mod_perl. I am following the 'mod_per 2.0 Source Code Explained' guide. Before doing any change at all I tried to run 'make source_scan' and I got some errors. Going through build/source_scan.pl I was able to tell which errors where generated from each instruction (see below), but this has not brougth me any further. Can anybody give me a hint about what I could do? Thanks! mod_per: 2.0 (checked out from CVS, Nov 26 2002) perl: 5.8.0 It's not working most of the time, as Apache source gets changed all the time. You need the patched Scan.pm from apache.org/~dougm/, but it doesn't seem to work for me with the latest cvs. Hopefully Gerald Richter gets his generalized version to work asap, so we don't rely on C::Scan anymore. When the scan doesn't work, you should manually add the functions to xs/tables/current/, which is pretty easy to do if you don't have many of them. And if you have some improvements to the scarce notes in the 'mod_perl 2.0 Source Code Explained' chapter, please send me a patch... thanks. ______ 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, mod_perl and cvsweb
Ilya Martynov wrote: On Mon, 25 Nov 2002 23:01:44 -0500, Geoffrey Young <[EMAIL PROTECTED]> said: Look in archives. I think many people had problems with IPC::Open2 under mod_perl. So far the best solution I know is just replacing it with IPC::Run. Seconded. Go with IPC::Run and you won't regret, since it works under mod_perl and gives you much more than the IPC::Open* family. GY> IPC::Run++ Question about IPC::Open2 under mod_perl seems to arise quite frequently. Maybe it should be added to mod_perl guide in 'Frequent mod_perl problems' section. done. will be online at the troubleshooting.html chapter on the next automatic update (within 6 hours). ______ 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 error compiling mod_perl on RH7.1
Witchy wrote: Thanks for that, Stas. I'll see if I can get my hands on 5.6.1 since the current release has too many dependencies to resolve with RH7.1 without the possibility of something getting Broken :) Doug says that we want 2.0 to compile under perl 5.6.0, even though you won't get all the features (e.g. perlio, on which other features depend) and you should remember that perl version is very buggy. In any case, if you try the current cvs you should be able to compile 2.0 with 5.6.0 again. -Original Message----- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: 11 November 2002 04:36 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: make error compiling mod_perl on RH7.1 Witchy wrote: Hi all, Trying to compile mod_perl 2.0 for my RH7.1/Apache 2.0.39 server and it falls over with this error: apr_perlio.c: In function `apr_perlio_apr_file_to_glob': apr_perlio.c:573: `IoTYPE_WRONLY' undeclared (first use in this function) apr_perlio.c:573: (Each undeclared identifier is reported only once apr_perlio.c:573: for each function it appears in.) apr_perlio.c:577: `IoTYPE_RDONLY' undeclared (first use in this function) make[3]: *** [apr_perlio.o] Error 1 make[3]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs/APR/PerlIO' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs/APR' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs' make: *** [subdirs] Error 2 When I ran 'perl Makefile.PL' etc with the correct location for my apache setup the only thing it complained about was the fact I was using Perl 5.6.0 and it recommended 5.6.1 or above. Before I trawl the dependencies tree trying to install a later version has anyone seen that problem before and do I really need to upgrade my perl installation? As somebody else has pointed out you won't have a problem if you run Perl 5.6.1 or higher. Let me check with other developers if 2.0 will eventually require 5.6.1 which is much better thatn 5.6.0. Or whether we should backport things to 5.6.0 as well. The reason is that macros IoTYPE_WRONLY and IoTYPE_RDONLY were introduced in 5.6.1. ______ 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: adding "company Foo uses mod_perl" ads
Ken Y. Clark wrote: On Tue, 26 Nov 2002, Stas Bekman wrote: advertising the merits of your product or going down on your competitors ^^ For future reference, this phrase has certain ... um ... sexual connotations, at least in the US. :-o And that's exactly what some of them do... without involving implicit sex 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: mod perl 2.0 /Apache 2.0
[ replies should go to the list and not to me :( ] Rick Tan wrote: It works with Apache 1.3.x/mod_cgi. Apache 2.0/mod_cgi doesn't work either. that's what I thought. Contact the httpd list then as this is not a mod_perl problem: http://httpd.apache.org/lists.html#http-users Stas Bekman wrote: Rick, mod_perl questions should go to the modperl list. thanks. http://perl.apache.org/maillist/modperl.html Rick Tan wrote: I have been experimenting with mod_perl for the first time in the past week. My frustration level emanates from making old cgi scripts to work with mod_perl/apache 2.0. The scripts were written to be invoked as http://some.server/myscript/other_path? The script name in this case is "myscript", other_path is part of the path_info pointing to some data repository on the server. The combination of mod_perl/Apache 2.0 seems to think that the cgi script is called "myscript/other_path", it is unable to parse these data. Am I missing some directives for mod_perl to effect this? The same script work with Apache with no mod_perl installed. Does it work with Apache 1.3 or 2.0 using mod_cgi instead of mod_perl? You don't provide the relevant configuration section, so it's hard to tell. ______ 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
adding "company Foo uses mod_perl" ads
As I was leaving Vegas I saw that billboard saying: Adidas uses SAP And I suppose that they run a bunch of similar ads using other big companies names. I think this is an interesting approach of advertising, where instead of advertising the merits of your product or going down on your competitors, you use a concrete example of a well known company that uses your software. So I thought to myself that in addition to our collection of: http://perl.apache.org/outstanding/sites.html http://perl.apache.org/outstanding/success_stories/index.html it'd be interesting to add some small ads similar to the ones used by SAP, though on the left menu bar at perl.apache.org, rather than billboards. e.g. "TicketMaster uses mod_perl" "InternetMovieDatabase uses mod_perl" "Slashdot uses mod_perl" etc. Of course if folks are willing to put them on their sites, that would be great too. But my point here is that when an IT person comes to perl.apache.org but who is still not convinced that mod_perl is something that he wants, this kind of local ads can help to make the right decision :) I guess a simple ImageMagic/GD script that glues the name on the prepared base and doing some color alternation will do the work of making several such ads without manual labour. And then we can randomly spread these at the perl.apache.org pages. Of course it'd be cool to use SVG, but unfortunately we are a long way before major browsers will support it and having users having these newer browsers :( ______ 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 /Apache 2.0
Rick, mod_perl questions should go to the modperl list. thanks. http://perl.apache.org/maillist/modperl.html Rick Tan wrote: I have been experimenting with mod_perl for the first time in the past week. My frustration level emanates from making old cgi scripts to work with mod_perl/apache 2.0. The scripts were written to be invoked as http://some.server/myscript/other_path? The script name in this case is "myscript", other_path is part of the path_info pointing to some data repository on the server. The combination of mod_perl/Apache 2.0 seems to think that the cgi script is called "myscript/other_path", it is unable to parse these data. Am I missing some directives for mod_perl to effect this? The same script work with Apache with no mod_perl installed. Does it work with Apache 1.3 or 2.0 using mod_cgi instead of mod_perl? You don't provide the relevant configuration section, so it's hard to tell. ______ 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: Subroutine main redefined?
Jan Theofel wrote: Hello, Am Mon, 2002-11-25 um 01.14 schrieb Stas Bekman: Jan Theofel wrote: [Sun Nov 24 17:59:45 2002] shop.pl: Subroutine main redefined at /home/www/[...]/shop/engine/shop.pl line 19. This is a warning, not an error. Ok, but why do I get this warning? I don't redefine the sub. That shouldn't happen. Since under PerlRun the namespace is cleaned before the new request. Any chance you have it defined twice in the same script? Google found some problems and solutions for that, but they all seemed to be for Apache::Registry and not for Apache::PerlRun. ::Registry and ::PerlRun are very similar, most things that apply to the former apply to the latter, see docs for more info. Is ::PerlRun like running ::Registry with the Apache configuration "PerlSetVar PerlRunOnce On"? Not completely. Docs are coming to help: http://perl.apache.org/docs/1.0/guide/intro.html#Apache__PerlRun That should be: PerlSendHeader on since you manually print your headers. Ok, this works. Thanks. ;) ______ 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, mod_perl and cvsweb
Ilya Martynov wrote: On Mon, 25 Nov 2002 18:27:54 +0900, Keith Watanabe <[EMAIL PROTECTED]> said: KW> Hi! KW> I was wondering if there are any known issues regarding IPC::Open2 KW> with mod_perl. Look in archives. I think many people had problems with IPC::Open2 under mod_perl. So far the best solution I know is just replacing it with IPC::Run. Seconded. Go with IPC::Run and you won't regret, since it works under mod_perl and gives you much more than the IPC::Open* family. ______ 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: Static mod-perl with apache 1.3.27 on OS 10.2.2
Randall Perry wrote: Trying to compile static mod-perl using the following configs. You don't say what configs. Please review the build process at: http://perl.apache.org/docs/1.0/guide/install.html moreover when reporting problems make sure to follow these guidelines: http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems (hint: look at the shortcuts menu on the left at all pages on perl.apache.org) Everything runs without error, except libperl.a is never built in apache_1.3.27/src/modules -- get the following error: ===> src/modules/libperl.a /bin/sh: cd: libperl.a: No such file or directory Can someone help? -- ______ 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: [OT] Stack Operation
Tim Tompkins wrote: But push()ing and pop()ing is not what the original poster wants to do. He wants to splice(). It doesn't matter if he's talking about treating a stack in the traditional sense, and it doesn't matter that splice is not as efficient as push or pop. What matters is that he knows how to accomplish what he requested. Any chance you can find a more appropriate forum for discussing perl basic things? Thank 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: Problem with Stream-oriented Output Filter
Esteban Fernandez Stafford wrote: [...] As you can see the filter is called twice and therefore there is one line that gets broken in two. I could always store $left_over in the context of the filter and prepend it to what I read when the filter starts again. But the problem I find is that I have no way to know when the "real" eos is reached in order to flush $left_over to the output. I thought there may be some sort of $filter->eos() call or something. Yes, there is a problem. Thanks for the report! If you are on the dev list we discuss how exactly to implement a good solution. If not I'll post the solution once we have one. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Subroutine main redefined?
Jan Theofel wrote:
Hello,
I have a very simple perl script which I try to run with
Apache::PerlRun. After changing the directory section in the apache
configuration file and a restart I get no repsonse to my client and the
error file fills with:
[Sun Nov 24 17:59:45 2002] shop.pl: Subroutine main redefined at
/home/www/[...]/shop/engine/shop.pl line 19.
This is a warning, not an error.
Google found some problems and solutions for that, but they all seemed
to be for Apache::Registry and not for Apache::PerlRun.
::Registry and ::PerlRun are very similar, most things that apply to the
former apply to the latter, see docs for more info.
Here's the script (a few comments snipped away):
--- snip ---
#!/usr/bin/perl -w
use strict;
use eqtools;
use eqdbtools;
&main;
1;
sub main {
# -- create a new session --
&open_db();
my $sid = &create_session();
&track_request($sid, "?THIS_IS_A_NEW_SESSION");
&close_db();
# -- forward the browser to the following page --
if($sid ne "")
{
print "Status: 302 Moved\n";
print "Location: /static.pl?sid=$sid&page=home\n\n";
}
else
{
&fatal_db_error("FATAL ERROR CREATING A NEW SESSION!", "-");
}
}
--- snap ---
And here is the section form my apache configuration file:
--- snip ---
AllowOverride AuthConfig
Order allow,deny
Allow from all
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI -Includes
PerlSendHeader off
That should be:
PerlSendHeader on
since you manually print your headers.
__
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: MySQL & prepared sql statements?
David Wheeler wrote: On Sunday, November 24, 2002, at 01:08 PM, Bas A.Schulte wrote: I'm wondering if I would gain (some) performance by preparing my sql statements once during ChildInit when using MySQL? Does it cache execution plans for sql statements? I know it makes a big difference on Oracle but I'm not sure what MySQL is like in this respect. MySQL doesn't have a prepared statement feature, so you wouldn't get the same kind of performance gain that you would with Oracle. That said, DBD::mysql does a bit of munging with your statements, and if you use prepare(), it does that munging only once per statement. The upshot: Use prepare() whenever possible to maximize performance. Even better, used prepare_cached() for statements you'll be using a lot, and then they'll be prepared only the first time prepare() is called (per Apache child). Doing so will also make it easier to gain the performance benefit if you later decide to switch to a database such as Oracle that supports prepared statements in the database. What David said, plus your friendly docs: http://perl.apache.org/search/swish.cgi?query=prepare_cached&sbm=SecE&submit=search ______ 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 sub handler was called.
Stas Bekman wrote: Ruslan U. Zakirov wrote: Hello, all! May I understand in my handler sub how it was called? Was it called by Apache process in stacked handlers chain or it was called by some other module with call "MyMod::handler($r)"? Could i do it without adding some special parametrs? perldoc caller perldoc -f caller Thanks, Issac __ 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: Reading configuration problem under mod_perl2
Yuriy Syrota wrote: Hello, folks. I'm porting apache module (from version 1 to version 2) and got the following problem: The module can't read itself configuration from httpd.conf. I traced out ap_find_command_in_modules() in httpd and realized that in this function modules list doesn't contain my module's entry. Although httpd calls my per-server configuration creator. How can it be? Just to make things clear, does this happen when you load modperl and works fine without 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
Re: Problem using variable with @PerlSetVar
Christopher Grau wrote:
Hi,
I have a fairly simple problem, but haven't had much luck finding the
solution on Google or the mailing list archives. Basically, I have this
code in httpd.conf:
print "Enter some value you don't want written down: ";
my $value = ;
chomp $value;
print "value = '$value'\n";
# The code works if I do this...
# $value = "Foobar";
push @PerlSetVar, ["Foo" => $value];
The value in $value prints to stdout, but the variable "Foo" doesn't get
set to $value. However, if I were to set $value to something
explicitly, as in the comment above, the code works fine.
Based on that, I'm guessing the problem lies with reading from .
What am I missing here?
This one was tricky. The reason for this misterious behavior lies in
fact that Apache restarts itself on start. The input is prompted
once and then on the restart $value gets overwritten with undef. If you
check your error_log you will see several warnings and errors regarding
this code. among which:
[Sun Nov 24 19:45:40 2002] [error] (25)Inappropriate ioctl for device:
: PerlSetVar takes two arguments, Perl config var and value
First of all, it's easier to debug with:
use Apache::PerlSections();
$Apache::Server::SaveConfig = 1;
# set @Perl* here
print STDERR Apache::PerlSections->dump();
notice the dump(). Remember that on start STDERR goes to the console. On
the restart it goes to error_log, therefore you want to watch both, as
it will be called twice.
using the dump() you will see that on restart no value is passed.
Here are two possible solution that work:
print "Enter some value you don't want written down: ";
$mytmp::value ||= ;
chomp $mytmp::value;
print "value = '$mytmp::value'\n";
push @PerlSetVar, ["Foo" => $mytmp::value];
here, we use a global variable, so it survives the scope re-entrance. If
may return 0, you want to do:
$mytmp::value = unless defined $mytmp::value;
instead
Another longer but more self-documenting solution is as follows:
if ($Apache::Server::Starting) {
print "Enter some value you don't want written down: ";
$mytmp::value = ;
chomp $mytmp::value;
} else {
print "value = '$mytmp::value'\n";
push @PerlSetVar, ["Foo" => $mytmp::value];
}
See also:
http://perl.apache.org/docs/1.0/guide/config.html#Apache_Restarts_Twice_On_Start
p.s. for now let's keep this trickery in the archives, if the question
is repeated, will add the answer to the docs.
__
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: Where do you specify APR::HOOK...
Erich Oliphant wrote: Ok, thanks now it makes sense ;) It's in the mp2 docs and it wasn't clear if it was not implemeted or the docs were behind the code. Maybe you guys could stick a note on it or something. done. - Original Message ----- From: "Stas Bekman" <[EMAIL PROTECTED]> To: "Erich Oliphant" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, November 11, 2002 5:45 AM Subject: Re: Where do you specify APR::HOOK... Erich Oliphant wrote: Hi, I am trying to place a handler at the end of the list of PerlLogHandler's. I know I want to use APR::HOOK_REALLY_LAST but I'm not sure how or where to specify it for my handler. I tried "PerlLogHandler My::Handler APR::HOOK_REALLY_LAST" in the httpd.conf file w/ no success. Should it be in the handler code itself? That API doesn't exist yet in mod_perl 2.0. I believe the reason for that is that Apache hooks ordering API wasn't finalized yet. __ 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: passing Apache::Request object
Marc Lambrichs wrote: Hi All, I want to save my Apache::Request object in an PerlInitHandler called Initialization and later on during the life cycle of the request call a Initialization->get_request() method to use it again. perldoc Apache::Request: instance The instance() class method allows Apache::Request to be a singleton. This means that whenever you call Apache::Request->instance() within a single request you always get the same Apache::Request object back. This solves the problem with creating the Apache::Request object twice within the same request - the symptoms being that the second Apache::Request object will not contain the form parameters because they have already been read and parsed. my $apr = Apache::Request->instance($r, DISABLE_UPLOADS => 1); [... more in the manpage ...] ______ 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 sub handler was called.
Ruslan U. Zakirov wrote: Hello, all! May I understand in my handler sub how it was called? Was it called by Apache process in stacked handlers chain or it was called by some other module with call "MyMod::handler($r)"? Could i do it without adding some special parametrs? perldoc caller __ 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 Can I Install ModPerl on My ISP-based Website???
David Simcik wrote: Thanks for the link... So basically, according to the link listed below, there IS NO good way to install modperl for just a local user account (I can't work some .htaccess magic,etc.?)? I guess that would make sense -- seems like modperl is tightly bound with the apache installation (one of dem dere apache modules I take it). The memory/resource issues mentioned on that page facing ISPs seem a bit justified as well. Sigh. You will probably need to have an installation per user if security is an issue. Various possible solutions are discussed in that doc. mod_perl 2.0 with perchild mpm should resolve the ownership problem, partially similar to what suexec does. David -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 11:30 AM To: David Simcik Cc: Modperl Subject: Re: How Can I Install ModPerl on My ISP-based Website??? David Simcik wrote: I would LOVE to use mod_perl on my personal website -- I have the diskspace to do so, but the question remains as to whether or not I have the rights. The rights to do what? Can anyone point me to a guide for this? I've poked around the mod_perl site and didn't find anything too specific. My guess would be: http://perl.apache.org/docs/general/multiuser/multiuser.html _________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.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: Problem with Stream-oriented Output Filter
Esteban Fernandez Stafford wrote:
Hello,
I am currently developing a modperl filter that uses the streaming
approach. I started off with the example in
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Stream_oriented_Output_Filter
sub handler {
my $filter = shift;
my $left_over = '';
while ($filter->read(my $buffer, BUFF_LEN)) {
$buffer = $left_over . $buffer;
$left_over = '';
while ($buffer =~ /([^\r\n]*)([\r\n]*)/g) {
$left_over = $1, last unless $2;
$filter->print(scalar(reverse $1), $2);
}
}
$filter->print(scalar reverse $left_over) if length $left_over;
Apache::OK;
}
This seems to work OK when the file is small (smaller than 8192). When
the file is larger, then there is a line that gets cut. This is
because the handler gets called more than once for big requests. Is
there a nice way to overcome this problem? I was thinking using
filter context to store variable $left_over, but then I dont know how
to detect the "real" end of the stream.
The problem is that I've written a patch that makes the $filter->print()
outside the while() loop work, but it was never committed. So the doc
is out of sync with the core code. For now please apply this patch:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=102828686110352&w=2
I'll see that it gets into the core asap.
--
_____
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: libperl.so: undefined symbol: PL_dowarn
Dennis wrote: Hi, I have compiled mod_perl en installed it without any errors but wen i try to start Apache witch mod_perl then i get the following error: Starting Apache 1.3.27: Syntax error on line 274 of /opt/apache-1.3.27/conf/httpd.conf: Cannot load /opt/apache/libexec/libperl.so into server: /opt/apache/libexec/libperl.so: undefined symbol: PL_dowarn /opt/apache/bin/apachectl startssl: httpd could not be started As gozer suggest next to me, you might have a stray header file from an older perl, which happened to be picked by the build. Any chance you have a few installations of perl? Trying install from scratch? -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: How Can I Install ModPerl on My ISP-based Website???
David Simcik wrote: I would LOVE to use mod_perl on my personal website -- I have the diskspace to do so, but the question remains as to whether or not I have the rights. The rights to do what? Can anyone point me to a guide for this? I've poked around the mod_perl site and didn't find anything too specific. My guess would be: http://perl.apache.org/docs/general/multiuser/multiuser.html _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: make test failed when installing mod_perl 2.0 on Linux
please remember to properly report problems, as explained at: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems (hint: the shortcuts menu on the left side of any page of perl.apache.org) if you don't provide all the required details it makes it hard to guess what configuration you've the problem with. I had this problem a while ago with the worker mpm over 5.8.0: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=101128927611980&w=2 but I think it should be OK now. I am new to linux and mod_perl. We are running perl 5.8.0 and apache 2.0.43 on linux. First time we are trying to install mod_perl2. But the "make test" failed completed. Here is the error_log reads: << END in modperl_extra.pl, pid=19385 [Thu Nov 21 11:24:45 2002] [notice] Apache/2.0.43 (Unix) mod_perl/1.99_07-dev Perl/v5.8.0 configured -- resuming normal operations [Thu Nov 21 11:24:45 2002] [info] Server built: Nov 20 2002 15:10:20 [Thu Nov 21 11:24:45 2002] [debug] prefork.c(1039): AcceptMutex: sysvsem (default: sysvsem) [Thu Nov 21 11:24:46 2002] [error] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 23) line 3. [Thu Nov 21 11:24:46 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:24:46 2002] [error] [client 127.0.0.1] Can't locate TestHooks/init/first.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl- . [Thu Nov 21 11:26:32 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:26:34 2002] [error] failed to resolve handler `TestHooks::init::first' [Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl-1.99_07/t /home/dsun/mod_perl-1.99_07/blib/lib/Apache2 /home/dsun/mod_perl-1.99_07/blib/arch/Apache2 /home/dsun/mod_perl-1.99_07/Apache-Test/lib /home/dsun/mod_perl-1.99_07/lib /home/dsun/mod_perl-1.99_07/blib/lib /home/dsun/mod_perl-1.99_07/blib/arch /home/dsun/mod_perl-1.99_07/t/response /home/dsun/mod_perl-1.99_07/t/protocol /home/dsun/mod_perl-1.99_07/t/hooks /home/dsun/mod_perl-1.99_07/t/filter /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/perlmodule-vh /home/dsun/mod_perl-1.99_07/t/htdocs/testdirective/main /usr/local/lib/perl5/5.8.0/i586-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i586-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl) at (eval 25) line 3. [Thu Nov 21 11:27:27 2002] [error] failed to resolve handler `TestProtocol::echo' [Thu Nov 21 11:27:27 2002] [error] Can't locate TestProtocol/echo.pm in @INC (@INC contains: /home/dsun/mod_perl- [Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC [Thu Nov 21 11:27:29 2002] [error] failed to resolve handler `TestProtocol::echo_filter' [Thu Nov 21 11:27:29 2002] [error] Can't locate TestProtocol/echo_filter.pm in @INC (@INC . [Thu Nov 21 11:27:29 2002] [info] removed PID file /home/dsun/mod_perl-1.99_07/t/logs/httpd.pid (pid=19387) [Thu Nov 21 11:27:29 2002] [notice] caught SIGTERM, shutting down END in modperl_extra.pl, pid=19387 >> I've checked the actual module in @INC. It does exist. Then I've searched throu the mod_perl archive, and made the change as http://www.mail-archive.com/modperl@apache.org/msg29648.html suggested. But "make test" failed again. This time, the error changed from the "Can't locate TestHooks/init/first.pm in @INC... " to "Can't locate TestHooks/trans.pm in @INC...". Other errors remain the same. Any suggestions? Dawn -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Migrating from CGI.pm to Apache::Request question.
Jesse Erlbaum wrote: Hi Coexec -- I am experienced with using the CGI.pm, and now I want to rewrite all of my CGI's using mod_perl and Apache::Request. Maybe a silly question: What are you hoping to gain by doing this? Speed. Apache::Request's guts are implemented in C, CGI.pm is Perl. If you do a lot of processing the speed improvement is significant. See: http://perl.apache.org/docs/1.0/guide/performance.html#Apache__args_vs__Apache__Request__param_vs__CGI__param _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: References for modperl usage in financial institutions?
Marcin Kasperski wrote: Thanks for all the people who sent me the references (both here and to private email). Maybe it would be good idea to add some such references to the 'sites running modperl' page. My business client after taking a look at http://perl.apache.org/outstanding/sites.html said 'nice, but there are mostly technical sites, almost no business...' Yes, please post your success stories here and we will add them to http://perl.apache.org/outstanding/sites.html or http://perl.apache.org/outstanding/success_stories/index.html depending on how descriptive the story is. Looking forward to add your stories... _____ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: am i heading for disaster... ?
Noam Solomon wrote:
In the process of building apache_1.3.27 / mod_perl 1.3.27 /
openssl0.9.6g / mod_ssl mod_ssl-2.8.12-1.3.27 on a Solaris OS 2
UltraSparc, with Perl 5.8, the apache make failed because of an
undefined "url_delims". I was using the method where you build mod_ssl,
then build mod_perl, then configure apache, loading mod_perl statically.
Anyway, I poked around and found that indeed the uri_delims.h file in
src/main was empty! So still in src/main, I manually ran "gcc
gen_uri_delims.c", then ran "a.out > uri_delims.h" to regenerate that
header file, and got this.
/* this file is automatically generated by gen_uri_delims, do not
edit */
static const unsigned char uri_delims[256] = {
T_NUL,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,T_HASH,0,0,0,0,
0,0,0,0,0,0,0,T_SLASH,0,0,0,0,0,0,0,0,0,0,T_COLON,0,
0,0,0,T_QUESTION,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
};
Then when I ran make again, everything was hunky-dory. Now what I want
to know is, why would this have happened in the first place? Is it a
sign that something is fundamentally wrong with the build, but I just
haven't seen it yet? Or should I just breathe easy and hope for the best?
I doubt this has anything to do with mod_perl. The build hasn't changed
in years, so it must be some external glitch. For example you might have
run out of disk space, so when it was writing the file it was zeroed.
--
_________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mp2.0 w/Apache 2.0, DBI setup??
Robert Kohler wrote: Randy Kobes wrote: On Mon, 18 Nov 2002, Robert Kohler wrote: I am having difficulty getting Apache 2.0.43, perl 5.6.1, and mod_perl 1.99_07 to work together. Trying to authenticate users based on a MySQL table. All compiles and installs. I installed Apache-DBI-0.89 perl module. In configuring, I keep getting "Seg faults". Can someone let me know if I am even setting up the config file correctly for Apache. Seems I have searched all the archives, and keep getting conflicting information... Are you using the latest versions of DBI and DBD::mysql? If not, does this still happen with the latest versions? DBI 1.21 DBD::mysql 2.0.11 Note the most current, but I can't modify this as it is in production currently. I can try testing on a completely different system if need be. As Randy has mentioned you need DBI-1.30 and your problem should go away. It did for me :) -- _________ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: [OT] Persistant MySQL connections in Apache 2
Issac Goldstand wrote: This is really a C API thing, but I was wondering if Apache2::DBI people can help me shed some light on this... I'm not sure what's the Apache2::DBI question, but we (Tim, Hugo, Eric at el.) have discussed the Apache::DBI for threaded apps at the last TPC and the conclusion was that we need to write a generic Perl Thread::DBI module to work with threaded Perl and then use Apache::DBI on top of it. Some of this was discussed on the dbi-dev list, but as far as I know nothing was developed so far. If you want to discuss the design, which is not trivial, and implementation, it's probably the best to do that on the dbi-dev list. - Original Message - From: "Kent Fitch" To: <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 5:37 AM Subject: Re: [apache-modules] Persistant MySQL connections in Apache 2 Hi Issac, From: "Issac Goldstand" Subject: [apache-modules] Persistant MySQL connections in Apache 2 Hi all, I'm a rookie C API programmer (mod_perl was just so much *easier* most of the time :-)), and am working on coding a module to with in my front-end Apache 2/mod_proxy server. The idea of the module is to provide access to the front-end server with a list of "blacklisted" IPs which are stored in a MySQL database. So I'm thinking the module's child_init should open the connection to the MySQL database and then the access_handler can grab the MySQL connection from the child-pool. Yes, but beware that in a threaded Apache run-time, there could be many threads fo execution processing many requests "simultaneously" in your child process, so you'll have to arrange to lock the connection whilst a thread is using it and possibly have a pool of them. See "Thread Safety" http://httpd.apache.org/docs-2.0/developer/thread_safety.html But the problem is that I would *like* for the connections to the database be closed before the pool is simply swept clean upon destruction. I would think that that would be a "good thing to do" - maybe I'm wrong... Yes - you should register a cleanup function on the pool you allocate the data structures for the connection(s) from in your "init". See these notes on pooling (which may be a bit 1.3-ish and hence out of date, but the ideas are relevant): http://httpd.apache.org/docs-2.0/developer/API.html#pools and see the apr_pool_cleanup_register api Kent Fitch -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Hellp! mod_perl worked fine then added modssl and now apachewon' t start
Mitchel, Jennifer (Jem) wrote: Hi all, I am still new to all of this. I had Apache 1.3.22 with mod_perl included and the Authenitcation hook enabled. Everything was fine. Then I imstalled my OpenSSL and generated my key, got my server certificate from my csr etc fine. The certificate has been verified. I then with mod_ssl-2.8.5-1.3.22 did ./configure \ --with-apache=/web/server/apache/1.3.22-source \ --with-ssl=/web/server/OpenSSL/0.9.6g \ --with-crt=/web/server/OpenSSL/0.9.6g/bin/serverPEM.crt \ --with-key=/web/server/OpenSSL/0.9.6g/bin/server.key \ --prefix=/=/web/server/apache/1.3.22 This went fine. make went fine. Because I used with-crt/with-key I skipped make certificate (yes serverPEM.crt and server.key are the real certificate and private key) make install goes fine. I stop Apache fine. Once start I get the following error Syntax error on line 1008 of /web/server/apache/1.3.22/conf/httpd.conf: Invalid command 'PerlModule', perhaps mis-spelled or defined by a module not included in the server configuration /web/server/apache/1.3.22/bin/apachectl start: httpd could not be started Please review: http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___openssl_ -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Namespace problem
Thomas Hilbig wrote: I am having a namespace problem that is a slight twist to that described in the 1.0 docs http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs My problem is even simpler, but worse. If I have two CGI programs using the same required script. Initially one works without any problems. Then if I call up the other script, each time I get an error saying the subroutine cannot be found. Refresh the browser and it works, but then the first one starts to give an error; Error message: Undefined subroutine &ModPerl::ROOT::ModPerl::Registry::home_httpd_qx_2dbin_gdtest1::goodDay called at /home/httpd/qx-bin/gdtest1 line 7. It's not any different, please read that section again. You must be hitting different children hence you see the problem with the first script. -- _____ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
ApacheCon mod_perl 2.0 presentation's handouts
If you come to ApacheCon and plan to go to the mod_perl 2.0 presentation on Wed, after the lunch, here are the handouts if you want to print them. The conference organizers won't give printed versions, in order to cut costs. So here it's: http://stason.org/talks/apachecon2002/presentation/mod_perl-2.0-presentation-handouts.pdf.gz If you come to my "mod_perl 2.0 by example" tutorial on Monday, I believe you will be given a printed copy of the handouts, so no need to bring your own copy. Older presentations/tutorials are available at the usual location: http://stason.org/talks/ See you next week. p.s. If you are looking for us Eric and I are staying in the room #1801 at Alexis Park Resort. _____ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: @INC + use Lib
Pierre Smolarek wrote: I've been having problems with use lib. I read the extract at http://perl.apache.org/docs/1.0/guide/porting.html#_INC_and_mod_perl and realised that you can hardcode @INC via httpd.conf or startup.pl. however, i tried adding PerlSetEnv PERL5LIB to a .htaccess file but that doesn't seem to work!? @INC is hardcoded at the server startup and gets reset after each request. Is there someway to isolate the paths to specific virtualhosts or directories? I tried adding it within a directory command in httpd.conf but it didn't seem to work. Look at: http://perl.apache.org/docs/1.0/guide/config.html#Is_There_a_Way_to_Modify__INC_on_a_Per_Virtual_Host_or_Per_Location_Basis_ http://perl.apache.org/docs/1.0/guide/modules.html#Apache__PerlVINC___Allows_Module_Versioning_in_Location_blocks_and_Virtual_Hosts ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Help - SEGFAULTS on 'PerlModule' after version upgrade
Rafiq Ismail (ADMIN) wrote: Ugggh: My software works with the 'original server settings', (apache 1.3.24/mod_perl 1.26) see below(1), under linux. It doesn't work with 'new server settings', (apache 1.3.26 / mod_perl 1.26) see below(2), under freeBSD. Symptoms: With the new build, I get seg faults with 'some' of the PerlModules included through PerlModule in various virtualhosts. Other modules work. These packages all run with strict and do not include any XS besides what may hide under the cover with DBI, Date::Calc and Template. I also have a headache. The packages were happily being included into my old build and there is nothing unusual about them. An strace displays the last couple of lines before a segfault as follows: See, http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems you need to send the gdb backtrace, not the strace's output. FWIW, I've had segfaults on 'use DBI' with mod_perl 2.0/perl 5.8.0, which have gone after I've updated the DBI package. Try to do the same. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Cleanup question
Jan Theofel wrote: Hello, I have a shop system wirtten in Perl which I now must switch to mod_perl bevor going live. The code is written with "use strict" and I think it is in biggest parts a "good" source. ;-) The question I have now is, that I have to switch the error handling. Until now, I display an error message to the users web browser and then die(). As I know, this is not a good idea unter mod_perl, especially because I use references on lager data structures and some objects in my code. I searched the web for a documentation about that topic and found some things wwhich are somehow confusing to me. Perhaps someone of you knows a documentation which explains who to do this properly? You can die() under mod_perl. See: http://perl.apache.org/docs/1.0/guide/porting.html#die___and_mod_perl Other relevant pages to read: http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_Errors_to_the_Client_Instead_of_error_log http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Exception_Handling_for_mod_perl http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Customized___DIE___hanlder ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: AB Segfault on mod_perl Handler
Richard Clarke wrote: List, Does anyone know why apache ab might segfault when accessing one particular mod_perl handler on my site? Is this something I could be doing wrong in my handler (I can't think what.. the page works find in all browsers). Richard, this has nothing to do with mod_perl, other than triggering a bug in ab. Which is not a *mod_perl* problem. You want to post a proper bug report including a core stack backtrace to the httpd-dev list. See: http://httpd.apache.org/lists.html#http-dev __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mp2/httpd2 perlio test fail & register_cleanup CGI.pm error
Philip Burrow wrote:
> Hi all. Read some nice things about mod_perl so I thought I'd try it. I
> tried mp1 with the latest 1.x of Apache but Apache just seg faulted if I
> tried to run it. So, I went on to httpd 2.x. Couple of problems though.
>
> Firstly, it fails 11/11 of the apr/perlio.t tests during make test. All
> other tests are fine.
Can you please run:
t/TEST -v apr/perlio
and also send the errors from t/logs/error_log.
without a detailed report we cannot know what the problem is.
Also in the future please use t/REPORT script to report problems, as
explained here:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
> Secondly, I get this error in the log when I try to
> run a CGI that uses CGI.pm:
>
> ModPerl::Registry: Can't locate object method "register_cleanup" via
package
> "Apache::RequestRec" at /usr/local/lib/perl5/5.8.0/CGI.pm line 270.
this method is defined in Apache::compat. What happens if you add
PerlModule Apache::compat
in httpd.conf. The latest CGI.pm (2.89?) loads this module automatically:
if ($mod_perl::VERSION >= 1.99) {
require Apache::compat;
} else {
require Apache;
}
> The CGI in question works fine without mod_perl.
>
> I'm using the startup script specified on
> http://perl.apache.org/docs/2.0/user/config/config.html and have
configured
> Apache as per that page. I have installed perl 5.8.0 from source as
per your
> documentation on the site. All related modules are latest versions from
> CPAN.
>
> Versions of software: RedHat 7.2, httpd 2.0.42, mod_perl 1.99_07, CGI.pm
> 2.89, kernel 2.4.19.
If this still doesn't help, can you please post a *short* CGI script
that reproduces the problem?
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@;stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl and apache 2.x
Jay Thorne wrote: Are there plans to make the new mod_perl backwards compatible? I tried a few months ago to move my faily large app to apache 2.x and mod perl and far far too many things are different. I'd love to experiment with the new code base, but this lack of compatibility is a show stopper for me. I don't have the time to re-code the entire thing. Failing that, is there a way to at least get print to work? Or have later mod_perl releases fixed that? Have you read the online docs? This should answer all your questions: http://perl.apache.org/docs/2.0/user/compat/compat.html#top if something is missing/unclear/wrong please let us know. Apache::compat includes most of the back-compat subs, but some are still missing. If you find such please report to the list. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Browse localhost
Dermot Paikkos wrote: Hi, I have noticed that since I installed mod_perl (v1.26) I can no longer point my browser at http://localhost. Previously I could view locally stored htdocs by either using http://localhost/doc_name.html or http://servername/doc_name.html. Is this normal or is my install not 100%? I can `telnet localhost 80` and get a server response with mod_perl showing. I get a server error if I point a browser from a different machine at the mod_perl server. I installed mod_perl into an existing apache server using apxs and everything=1. You must have configured to be handled by mod_perl. Fix that by using some other location for mod_perl handlers/scripts and you will get your normal DocRoot back. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0] compatibility suggestion
Josh Chamas wrote:
Hey mod_perl users/developers,
In short what I think we need is for the modperl2 perl-script
configuration directive to automagically load the Apache::compat
layer, please read below for why.
I am working on the Hello World benchmarks to get them running
against mod_perl2 so we can get some numbers comparing mod_perl1
against it, and meanwhile having to port to Apache2/mod_perl2
for the first time, in this case all of the benchmarks.
What struck me odd was that even the simplest of handlers would
not run directly under mod_perl/1.99_05-dev, as in:
sub handler {
my($r) = shift;
$r->content_type('text/html');
$r->send_http_header();
$r->print('Hello ');
$r->print('World');
200;
}
In this case the error was about content_type() not being implemented
which I could fix by adding:
use Apache::compat;
Many functions were renamed because they were renamed in Apache 2.0 API.
Worse, some functions are now have gone (e.g., send_fd). mod_perl keeps
a consistent API with Apache API.
Because some functions are no longer supported by Apache and were
replaced by similar functionalities which don't map 1:1 to the old
functions, Apache::compat provides a slower perl implementation for
them, but in the long run for production use you don't want to use
Apache::compat.
If it is the case that even the most trivial of applications
need Apache::compat, then why not load the Apache::compat layer
automatically? If performance is an issue, or code bloat or
what not, then perhaps *Apache::compat* layer could be added
only in case of using the *perl-script* config directive,
instead of the new modperl directive.
As Doug explained on the dev list, "perl-script" handler is the normal
mod_perl handler, it's not a backcompat handler.
Just load the Apache::compat if you need it while the dust settles down.
CGI.pm 2.89 already does that.
______
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@;stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: When does mod_ssl register input/output filter
Hideki Noma wrote: While constructing process connection handler employing bucket-brigade feature of Apache 2, I encountered some problem. I am trying to handle protocols other than HTTP and most of them starts communication from sending server hello message. When SSL handshake takes too long, communication fails. Process flow goes like this Apache: TCP/IP connection mod_ssl: SSL handshake starts Handler: Process handler starts Handler: Tries to send data to client -> send bucket-brigade to output_filters mod_ssl: SSL handshake done -> register input/output_filter If the handler can detect when the output_filter is ready, it will be fine, however there seems to be no functions to detect such events. Do you know how to detect SSL handshake is complete, or is there other solution? If I understand you correctly the problem is not happenning in the mod_perl land but on the mod_ssl land. Isn't the SSL handshake timeout configurable? The output_filter is ready to accept the data as soon as you put it on the stack or as soon as it has finished processing the brigade it happens to hold and returns to grab the next one. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Makefile 'PERL=' definition.. 1.99_07, and previous releases
Lester Vecsey wrote:
In the Makefile that gets generated there are some PERL= and FULLPERL=
statements that get set to whichever perl you ran on the original
Makefile.PL file. For example I ran /usr/bin/perl-5.8.0-threaded on it, and
they got set properly. The problem is theres an additional 'MakeMaker macro
section' down lower in the Makefile that gets generated that just seems to
always default to /usr/local/bin/perl, instead of any custom one that is
specified when running the original perl on Makefile.PL.
I just thought I'd point this out and ask if this was intentional or an
oversight. I manually changed it and was able to finish doing a 'make
install', which was previously hanging up on the 'pure_install' section
because it invoked the wrong perl executable.
So that takes care of the problem I posted about a week ago ;) Now off to
finish testing this version of mod_perl.so..
--
# --- MakeMaker macro section:
MODPERL_MAKEFILE = Makefile.modperl
#PERL = /usr/local/bin/perl
PERL = /usr/bin/perl-5.8.0-threaded
APACHE_PREFIX =
MOD_INSTALL = $(PERL) -I$(INST_LIB) -I$(PERL_LIB) -MModPerl::MM \
-e "ModPerl::MM::install({@ARGV},'$(VERBINST)',0,'$(UNINST)'
<mailto:{@;ARGV},'$(VERBINST)',0,'$(UNINST)'>);"
If you look at Makefile.PL it has the following code:
ModPerl::MM::WriteMakefile(
[...]
macro => {
[...]
PERL => $build->perl_config('perlpath'),
which essentially does:
require Config;
PERL => $Config{perlpath},
meaning that your perl's Config.pm is wrong. Check what you get when you
run:
% /usr/bin/perl-5.8.0-threaded -V:perlpath
does it print '/usr/bin/perl-5.8.0-threaded' or '/usr/local/bin/perl'
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@;stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: how to detect a broken connection using mod_proxy
giorgos wrote: hi all, i am running standard setup with one plain apache with mod_proxy and a mod_perl apache to which all mod_perl requests are directed by the proxy module. i want to be able to detect when the client connection breaks but all standard recipes like the one mentioned in p.147 of the cookbook don't work due the use of mod_proxy. does anyone know of a trick to detect when the connection is broken in such a scenario so that i can free up cpu resources? (i have a set of 4 heavy sql stm's. after each one of them i would like to check if the client is still there so that i will proceed to the next one or just return OK and forget about the request). As far as I know you can't do that, since mod_proxy doesn't cooperate with the backend. Anybody knows of similar to mod_proxy modules that do play nicely with the backend regarding aborted connections? ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: perl5/i386-linux/CORE/perl.h small "fix", dont know where tosend it
[EMAIL PROTECTED] wrote: Hi All, just started to play with perl2 + apache2 and after getting borred with warnings about redefinition of macro VOIDINFO, I've putted there #ifndef - I don't know how to make patch files, but if any maintainer reads this, can you please add following to perl5/i386-linux/CORE/perl.h ? #ifndef VOIDUSED #define VOIDUSED 1 #endif Martin, please always specify the version of the sw you are talking about? How are we supposed to guess which perl version you are talking about? In any case, this warning has been solved in perl 5.8.0 and you will still see it with 5.6.1. The problem with fixing 5.6.1 is that its successor 5.6.2 may be released or not at an unknown date. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp 2] Bug report - mod-perl install process.
Ian Stuart wrote: Server Version: Apache/2.0.39 (Unix) mod_perl/1.99_07-dev Perl/v5.6.1 I believe that the install process does not test for the presence (or lack of..) of the /modules directory. This causes a problem during the mod_perl installation as the pseudo-command "cp $SOURCE/mod_perl.so $SERVER/modules" creates a large file called "modules", not a file called "mod_perl.so" within a directory called "modules" [...] Indeed, it doesn't. Thanks for the report. Does the following patch solve the problem? I'm not quite sure how portable it is, but neither ExtUtils::MakeMaker nor %Config provide entries for test_d and mkdir. Index: lib/Apache/Build.pm === RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v retrieving revision 1.107 diff -u -r1.107 Build.pm --- lib/Apache/Build.pm 29 Aug 2002 02:00:56 - 1.107 +++ lib/Apache/Build.pm 11 Nov 2002 15:37:06 - @@ -1057,6 +1057,7 @@ lib: $(MODPERL_LIB) install: + test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_DSO) && \ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR) -- ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: httpd - where are these zombies coming from?
Tim Gardner wrote: I'm having trouble with zombies. Red Hat 7.1 on a Dell server with 1 GB memory. The following ps output shows a somewhat typical output. Sometimes there are no zombies, but most of the time there are several, and often as many as this. Performance often seems sluggish, and I am assuming that this is because of this problem, though I don't know that for sure. Turning off the database lowers usage and decreases the number of zombies, but I don't know if this is due to the database or to the lower usage. I can't figure out what is going on. Any help / suggestions would be much appreciated. [...] check http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing_Subprocesses_from_mod_perl in particular http://perl.apache.org/docs/1.0/guide/performance.html#Avoiding_Zombie_Processes my guess is that you use fork or its variations which leaves zombies. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: SafeCWD Status
Josh Bernstein wrote: Whats the staus of the cwd and SafeThread? Will it work with a threaded MPM in Apache 2 yet and safely change to the working directory of the perl script (safecwd). Arthur Bergman has started ex::threads::safecwd, but I'm not sure in what state the development of this module is. I remember he was asking for somebody to take over it, since he had too many p5p things to do. You can see the logic of this module in this article, second page: http://www.perl.com/pub/a/2002/06/11/threads.html?page=2 If you have the tuits to finishing it up, feel free to contact Arthur and offer help. As for SafeThread I haven't heard of this module in the perl land. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Compilation problems with mod_perl
Benny Jensen wrote: Hello, I'm trying to compile mod_perl for apache2. But i got a error message that i dont know how to solve. The following message is what i get: /LD_RUN_PATH="" cc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2/auto/APR/APR.so -lapr -laprutil /usr/bin/ld: cannot find -lapr collect2: ld returned 1 exit status / APR.so exist in following map: //usr/local/lib/perl/5.8.0/Apache2/auto/APR/APR.so/ If anyone could help me to solve it it's looking for libapr, not APR. You must have messed up the apache build step or missed it completely and don't have apache built yet. Review the installation steps at: http://perl.apache.org/docs/2.0/user/install/install.html#Condiguring_and_Installing_Prerequisites ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [BUG] Losing GET/POST-data
[...] Basically we are losing data sent to a mod_perl program. We request the page "page.fxml?name=al&adress=sweden&problem=huge". When our program receives this request it will only be "page.fxml" without any of the arguments sent. [...] I haven't followed the original thread, so I apologize if I repeat somebody else here. But from your description I'd suggest the following: You have to narrow the problem down after you are able to reproduce the problem at will. That means that you should use try to emulate multiply requests, for example with ab. See: http://perl.apache.org/docs/1.0/guide/performance.html#Benchmarking_Applications If you are able to do that and you know that the problem is on the server side and not caused by the clients who mess up with hidden fields or form elements. Next try to figure out who's causing the problem (assuming that it's a server side prob). e.g. this section uses three different ways to extract params: http://perl.apache.org/docs/1.0/guide/performance.html#Apache__args_vs__Apache__Request__param_vs__CGI__param Do you get the problem with all of them? Hope this helps. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mp2.0 Apache::Cookie
Rafael Amer Ramon wrote: Hi. I'm trying to upgrade my apache+mod_perl server form versions 1.3.27 (Apache) and 1.27 (mod_perl) to versions 2.0.43 and 2.0 but I have a problem with cookies. With mod_perl 1.27 I use Apache::Cookie from libapreq-1.0 and I cannot fount a similar module for mod_perl 2.0. It wasn't ported to 2.0 yet. The C core is almost completed though. Does anybody knows how I can handle cookies, send and get values, in a mod_perl 2.0 handler? Try using CGI::Cookie or check other similar modules on CPAN. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Where do you specify APR::HOOK...
Erich Oliphant wrote: Hi, I am trying to place a handler at the end of the list of PerlLogHandler's. I know I want to use APR::HOOK_REALLY_LAST but I'm not sure how or where to specify it for my handler. I tried "PerlLogHandler My::Handler APR::HOOK_REALLY_LAST" in the httpd.conf file w/ no success. Should it be in the handler code itself? That API doesn't exist yet in mod_perl 2.0. I believe the reason for that is that Apache hooks ordering API wasn't finalized yet. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Prevision
Udlei Nattis wrote:
when will be finished modperl2?
The short answer:
Never.
The long answer:
mod_perl 1.0 hasn't been yet "finished". Even though it's a robust piece
of sw it's a work in progress. New features are added and bugs are
fixed. So it's an ongoing process.
It all depends on what features do you need and whether they have been
already implemented in mod_perl 2.0. If certain features are missing,
you should either submit patches that add them or gently bug the dev
list that you need a certain feature which hasn't been
ported/implemented yet, certainly after you've lurked on the list for a
while, and actively participate in its testing once it has been added.
Here are several known issues:
mod_perl 2.0 doesn't implement args() and content() functions as they
were in 1.0. It provides a perl ("slower") backcompat implementation
that is added to help people migrate their code to 2.0. Apache::Request
should provide this functionality when it's ready. The C apreq library
for Apache 2.0 has been developed and in the good shape. Due to many
reasons we want this C library to be included in the httpd core, but it
didn't happen so far. Certainly the Perl glue code
(Apache::Request/Cookie) won't be written before the fate of the C
library is known. I hope that this issue is going to be resolved asap.
Registry scripts should work just fine with ModPerl::Registry. The only
issue is with CWD, which is not thread-safe. There is a workaround
module in works, which I think hasn't been released by Arthur Bergman
yet. Once it's released registry scripts will work as is.
If you are using the threaded mpm, there are many other potential issues
with threads. I'll discuss them at my mod_perl 2.0 tutorial and
presentations at ApacheCon next week. Stop by if you are interested.
Other then that the majority of the 1.0 features has been implemented I
think. And certainly there are heaps of new features that are already
available. Come to my talks where I'll cover the most interesting ones.
See the modperl-2.0/todo/* and modperl-2.0/STATUS for the lists of
things that haven't been done yet and let us know if something is
missing from these lists.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@;stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: installing a signal handler in module ..
Sylbert L wrote: Hi .. I need to catch a custom signal in my module. How do I do this ? I tried writing a signal handler .. & put it into my Responsehandler module .. but it doesn't seem to work. Is this possible ? How do I achieve this ? If you don't describe what your problem is, how can we possibly help you? Here is an example of using a custom sighandler to figure out where a process hangs: http://perl.apache.org/docs/1.0/guide/debug.html#Using_the_Perl_Trace ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2.0] Apache::SubProcess deFUNct sub-process
Imago wrote: Apache::SubProcess does not appear to be 'fully' working. This is quite possible. This module is a complete rewrite of the 1.x version. I've added some basic tests, but if you can supply a test that fails that'd be of a great help. Just remember that it should be as short as possible. See t/response/TestApache/subprocess.pm which is run as: t/TEST apache/subprocess Thanks! ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: HELP with mod_perl version
Alan Chung wrote:
Hi,
I have tried to upgrade my apache from 1.3.12 to 1.3.26 and openssl from
0.9.5a to 0.9.6g.
But when I upgraded mod_perl from 1.24 to 1.26 (it seems that I have
to), it could be compiled with no error but httpd couldn't be started
with the following error:
Apache.pm version 1.26 required!
/usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm is version 1.27
Perhaps you forgot to 'make install' or need to uninstall an old version?
Found: /usr/lib/perl5/site_perl/5.6.0/i686-linux/Apache.pm
From the error, it looks like I need to fall back to order version for
mod_perl (?),
So I did try to uninstall the current Perl and mod_perl and reinstall
again.
I even tried the different version of mod_perl (1.25, 1.27) but with the
same error.
Could anyone give me an advice?
Looks like you have either messed up several installations of mod_perl
or have forgotten to install the latest binary, which explains why it
requires 1.26. Check the timestamp on the httpd binary or the .so module
if you are using DSO. And go again through the install steps as
explained at http://perl.apache.org/docs/1.0/guide/install.html
If you want to make a complete cleanup of all older Apache modules prior
to installing the new ones, you could use find(1) to assist you to find
the older Apache:: modules. Something like the following:
find /usr/lib/perl5 -name 'Apache*'
and then deleting them if you are sure that this is what you want:
find /usr/lib/perl5 -name 'Apache*' -exec rm {} \;
Though be careful that you have a backup of things before you attempt to rm.
Notice that you don't have to uninstall *Perl* but only Apache modules.
______
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@;stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Quota module for Perl
Peter Kehl wrote: Hi, i am trying to install the Quota module for Perl, but following error occurs: I´ve installed RedHat 7.1 mod_perl 1.24_01-2 perl 5.6.0-12 Has anyone got an idea? Certainly. Quota.pm has nothing to do with mod_perl. Please ask the author of that module. Thank you. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Peek and perl 5.8.0
John Siracusa wrote: Does anyone have Apache::Peek working with perl 5.8.0? I can't get it to build, and I can't find the symbols it's (apparently) missing anywhere in perl 5.8.0's header files. Example: [...] Doug MacEachern has hacked Devel::Peek 0.95 to work with mod_perl. The current Apache::Peek version is 0.9501. It works with Perl versions < 5.8.0 and mod_perl 1.x. The attached package is a similar hack that works with Perl 5.8.0 and mod_perl 1.x. Doug's hack doesn't compile with perl 5.8.0, since Devel::Peek, which it copies, has been heavily rewritten and uses internally APIs which didn't exist before. I took a different approach and instead of overriding PerlIO functions (the approach which doesn't work anymore) I've simply supplied a very simple PerlIO layer that only knows to write data to the client using the request_rec object. I've done only very basic testing, so bugs are possible. Let me know if you spot any. I'm not sure what's the best approach to take in order to distribute this package. Whether to somehow extend it to support Perl < 5.8.0 and thus merge with Doug's version, or simply distribute it separately. Ideas and patches are welcome. TODO: The tests weren't adopted to use Apache::Test yet. Patches are welcome. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com Apache-Peek-1.00_035008.tar.gz Description: application/gzip
Re: newbie:How to get form input in mod_perl 2 since Apache::requestis not implemented yet ?
BuffaloRC Club wrote: Hi all, I am a newbie to mod_perl and going straight to mod_perl 2. If you want to play with 2.0 it's cool, but you may find that it's not yet ready for production, as not all APIs are available yet. On the other hand 1.27 is a *very* robust version. Have successfully written basic handler (API). Have not installed mod_perl 1.x Not using Apache::compat. ( Donot intend to use CGI.pm either ) In this case how to use methods from Apache::Request like $q->param() etc? I can get form data thru $r->read() but how to parse it ? Please point me to some documentation. have already checked perl.apache.org. Apache::compat is the only way to go for now (if you don't use CGI.pm). See http://perl.apache.org/docs/2.0/user/compat/compat.html#C__r_E_gt_content_ Apache::Request for Apache 2.0 is in works. The C version is pretty much completed, but it's not clear how it's going to be distributed. Once this clears out the perl glue code will be written. Join the [EMAIL PROTECTED] if you want to help and be the first one to know of new developments. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Errors after converting /cgi-bin to PerlRun
Frank Naude (FJ) wrote: Hi, I'm trying to convert my /cgi-bin directory to PerlRun as it only contain Perl scripts. However, after doing so, I get numerous errors like this: [Wed Nov 6 11:34:21 2002] [error] Can't locate object method "uri" via package "Apache::PerlRun" at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/PerlRun.pm line 212. I think it happens when processing a "require ;" contruct. [...] My software versions: Embedded Perl version v5.6.0 for Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_jk/1.2.0 mod_perl/1.24_01 [...] Would it be much of a trouble to upgrade to the latest mod_perl version 1.27? Most likely this problem has been fixed long time ago. [...] ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: make error compiling mod_perl on RH7.1
Witchy wrote: Hi all, Trying to compile mod_perl 2.0 for my RH7.1/Apache 2.0.39 server and it falls over with this error: apr_perlio.c: In function `apr_perlio_apr_file_to_glob': apr_perlio.c:573: `IoTYPE_WRONLY' undeclared (first use in this function) apr_perlio.c:573: (Each undeclared identifier is reported only once apr_perlio.c:573: for each function it appears in.) apr_perlio.c:577: `IoTYPE_RDONLY' undeclared (first use in this function) make[3]: *** [apr_perlio.o] Error 1 make[3]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs/APR/PerlIO' make[2]: *** [subdirs] Error 2 make[2]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs/APR' make[1]: *** [subdirs] Error 2 make[1]: Leaving directory `/home/adrian/mod_perl-1.99_07/xs' make: *** [subdirs] Error 2 When I ran 'perl Makefile.PL' etc with the correct location for my apache setup the only thing it complained about was the fact I was using Perl 5.6.0 and it recommended 5.6.1 or above. Before I trawl the dependencies tree trying to install a later version has anyone seen that problem before and do I really need to upgrade my perl installation? As somebody else has pointed out you won't have a problem if you run Perl 5.6.1 or higher. Let me check with other developers if 2.0 will eventually require 5.6.1 which is much better thatn 5.6.0. Or whether we should backport things to 5.6.0 as well. The reason is that macros IoTYPE_WRONLY and IoTYPE_RDONLY were introduced in 5.6.1. ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: make test fails
Kelton Joyner wrote: I am trying to upgrade to Apache 1.3.27 with mod_perl 1.27. I am currently running Apache 1.3.20 and mod_perl 1.26 on an HP-UX machine with hpux 10.20 with perl v5.6.1 built for PA-RISC1.1 . I ran configure on Apache to generate a config file with the additional modules I wanted, then did configure for mod_perl with the following perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 Then make && make test && make install The make worked with no errors. make test resulted in the following error output [...] Syntax error on line 3 of /usr/src/mod_perl-1.27/t/conf /httpd.conf: Invalid command '=pod', perhaps mis-spelled or defined by a module not included in the server configuration done Looks like you have messed up the installation steps when configuring apache separately. Please refer to: http://perl.apache.org/docs/1.0/guide/install.html#The_Flexible_Way ______ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: help getting started ..
Sylbert L wrote: > Thanks Stas, the code works just fine now. cool. I've fixed the online doc. > This is what i'd read : > > [Apache 1.3 is hardwired to speak only one protocol, HTTP. Apache 2.0 has > moved to more of a "server framework" architecture making it possible to > plugin handlers for protocols other than HTTP. The protocol module design > also abstracts the transport layer so protocols such as SSL can be hooked > into the server without requiring modifications to the Apache source code. > This allows Apache to be extended much further than in the past, making it > possible to add support for protocols such as FTP, SMTP, RPC flavors and the > like. The main advantage being that protocol plugins can take advantage of > Apache's portability, process/thread management, configuration mechanism and > plugin API.] > > So if this is true, then shouldn't it be possible for me to implment a > constant connection using Apache 2.0 ? See my previous reply. You need to implement a protocol handler. Here is the URL again: http://perl.apache.org/docs/2.0/user/handlers/protocols.html > PS : Any idea when the API docs will be available ? We want to reuse as much of the C headers Apache docs as possible, Lyle is working on writing a tool which will extract them. I'm not sure what's the status of things. Perhaps Lyle can give us an update. Meanwhile, if you aren't sure what APIs to use look in the t/ directory, where there are a few hundreds of tests that exercise most of the existing APIs. Overall 1.3 methods aren't very different in 2.0, there are just a bunch of new methods which are new. Also you can reuse the Apache C documentation as well. See: http://docx.webperf.org and http://lxr.webperf.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: help getting started ..
Sylbert L wrote:
> Hi,
>
> I'm just getting started with mod_perl. Was trying out the
> Apache::CommandServer sample code provided in the documentation, but I seem
> to get this error : Can't locate object method "run_access_checker" via
> package "Apache::RequestRec" at .
add:
use Apache::HookRun ();
in mod_perl 2.0 methods are spread across many modules for the maximum
performance and modularity. Once the API docs will be created you will
just have to search for the method in question and load the module that
has it. For now the easiest way is to grep the WrapXS dir:
.../modperl-2.0> grep -Ir run_access_checker WrapXS
WrapXS/Apache/HookRun/HookRun.xs:ap_run_access_checker(r)
WrapXS/Apache/HookRun/HookRun.c:XS(XS_Apache__RequestRec_run_access_checker);
/* prototype to pass -Wmissing-prototypes */
WrapXS/Apache/HookRun/HookRun.c:XS(XS_Apache__RequestRec_run_access_checker)
WrapXS/Apache/HookRun/HookRun.c:Perl_croak(aTHX_ "Usage:
Apache::RequestRec::run_access_checker(r)");
WrapXS/Apache/HookRun/HookRun.c:RETVAL = ap_run_access_checker(r);
WrapXS/Apache/HookRun/HookRun.c:
newXS("Apache::RequestRec::run_access_checker",
XS_Apache__RequestRec_run_access_checker, file);
> I'm using Apache 2.0.40, with mod_perl 2.0, Perl 5.8.0 on Red Hat Linux 7.2.
>
> Also, I was just reading up on the mod_perl handlers. Is it possible to
> modify the working of apache, such that, it doesn't close the connection
> with the client ? and the connection with the client remains a constant one
> until the client explicitly closes the connection ? Can this be done at a
> module level ? Or do I need to modify the Apache source to acomplish the
> same ? If its possible with mod_perl, which PerlHandler(s) need to be used ?
HTTP is a stateless protocol and while you have the KeepAlive
functionality to serve several requests over the same connection, you
cannot rely on that to keep the connection open.
Most likely you need to write a protocol handler for that. See:
http://perl.apache.org/docs/2.0/user/handlers/protocols.html
for examples and explanations.
> Thanks a whole lot. I've just recently purchased Oreilly's "Writing Apache
> Modules with Perl and C", but realized that it isn't too much of help, coz
> I'm dealing with Apache 2.0 & the book is all about Apache 1.3 & theres such
> a drastic difference between the two mod_perl implementations. Is there any
> other source of documentation / help I can find ?
Yes. There is enough to keep you busy for quite a while:
http://perl.apache.org/docs/2.0/user/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: flush problem
Udlei Nattis wrote:
> hi
>
> i have one problem
> look this source:
>
> use strict;
>
> $| = 1;
>
> my ($i,$r);
>
> $r = shift;
>
> $r->content_type('text/html');
>
> while ($i < 10) {
> $r->printf($i."\n");
> $r->printf("\0");
> $i++;
> sleep 1;
> }
>
> if you try in modperl 1.27 using windows xp and ie6 (others versions is ok)
> this code is ok in modperl 1.27 using windows xp and ie6
> but if you try modperl 2.0 (last cvs using perl 5.8.0) and httpd-2.0
> this code have one problem
>
> code don't send flush, print only when finish
> hu $| = 1 in modperl 2.0 dont run :/
Yup, this doesn't work yet. Use $r->rflush() for 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: Apache::PerlRun weird behavior?
valerian wrote: >>What mod_perl version are you using? Try to use the latest one. (though >>PerlRun didn't change for years). >> >>I've tested with: mod_perl 1.27 (perl 5.6.1 and 5.8.0) > > > This was the environment: > >mod_perl 1.21, perl 5.005, apache 1.3.9 >(all default packages that came with Debian 2.2r7) > > I finally had time to setup another machine with Debian 3.0 to test > with, and it works like it's supposed to. Very strange... I have no > idea what was causing the problem. The new software is: > >mod_perl 1.26, perl 5.6.1, apache 1.3.26 Most likely there was a bug in some older PerlRun. It's a good idea to run the latest stable sw if possible. Glad to hear that the problem has been resolved. __ 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::PerlRun weird behavior?
Perrin Harkins wrote:
> Stas Bekman wrote:
>
>> I think I've had enough coffee. PerlRun recompiles the code on each
>> request, meaning that it re-runs any BEGIN blocks on each request.
>> Meaning that My::Config will re-import %CF afresh.
>
> That makes sense. I was thinking that keeping track of which BEGIN
> blocks had run was somehow separate from the compilation process, but
> that seems pretty unlikely now that I think about it.
cool :)
>> Since use is almost the same as: require+import. require won't be
>> called because the module will be already in %INC, but import will be
>> always called.
>
> PerlRun resets %INC after each run, meaning that it should be compiling
> the used module again.
It doesn't reset %INC completely, it only resets entries that were
declared with 'package Foo' inside .pl:
for (keys %INC) {
next if $orig_inc{$_};
next if /\.pm$/;
delete $INC{$_};
}
so any .pm modules loaded from the perlrun script stay in %INC.
Moreover, if My::Config was preloaded it'll stay in %INC for sure.
> That doesn't explain why he's having trouble though.
If it was a real problem we would have received loads of reports, since
this is such a basic feature. Must be something else that messes up
things for him. He has never followed up with more details, so it's hard
to guess.
__
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::PerlRun weird behavior?
Perrin Harkins wrote:
> valerian wrote:
>
>> So the weird thing is that it runs fine the first time, but when I
>> reload the page, it doesn't show the variable I imported from
>> My::Config
>
>
> Try changing this:
>
> use My::Config;
>
> to this:
>
> require My::Config;
> import My::Config;
>
> BEGIN blocks are only run once in PerlRun/Registry, and PerlRun clears
> the current namespace after each request, erasing the aliases created by
> import.
> Of course I can't explain why this worked for Stas. Maybe there is
> something about the specific versions of Perl/mod_perl that affects this.
I think I've had enough coffee. PerlRun recompiles the code on each
request, meaning that it re-runs any BEGIN blocks on each request.
Meaning that My::Config will re-import %CF afresh.
It's simply to check, add to your script:
BEGIN { warn "BEGIN was called\n"; }
you will see the message on every reload.
Since use is almost the same as: require+import. require won't be called
because the module will be already in %INC, but import will be always
called. Again it's simply to check. Add to My::Config:
sub import { warn "import was called" }
and don't inherit from Exporter. Again you will see import() called on
each request.
> In general, you'd be better off just avoiding aliases and
> Exporter altogether, since they waste memory and can cause confusion.
Seconded. See
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Using_Global_Variables_and_Sharing_Them_Between_Modules_Packages
__
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: SetEnvIf Directive
Pierre Vaudrey wrote: > I'm trying to build a web site on the built-in Apache server of a Mac > OSX 10.1.5 machine . > Extract of httpd.conf is : > .. > LoadModule setenvif_modulelibexec/httpd/mod_setenvif.so > .. > AddModule mod_setenvif.c Pierre, this has nothing to do with mod_perl. Please 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
