Re: Apache::ASP #include virtual loses variables
Ime Smits wrote: | Well, I would like to suggest that you consider including !--#include | virtual-- in the Apache::ASP distribution, so that included files use the | same namespace. It doesn't make sense logically that include virtual | behaves differently from include file (other than the way the | filename/pathname is interpreted, of course). It does make sense to me, though. Consider one having very big (say 50k) include files being included from several other (say 100) scripts. Just sucking them in each script doing the include would cause *every* script growing by at least the size of the include. Now as Apache::ASP caches all compiled scripts, this would result in each httpd process growing by 50kB x 100 scripts = 5 MB, holding 98% redundant data. If DynamicIncludes are turned on, then file includes are compiled as subroutines, and executed as if $Response-Include() were called. Without this setting, includes text are added to the including scripts like you are saying. But this does not solve the virtual includes problem. A virtual include is supposed to be anything executed on the server, not just files, but the output from anything like some C cgi, or another .pl or so, and must therefore be processed as a separate subrequest. This is what Apache::SSI does. The problem here is that there is no way for the Apache::ASP script to catch the output from the apache subrequest to even try to compile it into its own script, even if you really wanted to do this. So this is why this is stays a separate feature to be handled by Apache::SSI, that it doesn't help at all to inline it into Apache::ASP, except some small performance benefit by not running the output through Apache::Filter -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: Apache::ASP #include virtual loses variables
So, there's no way in Apache::ASP to include a file by specifying a path relative to DOCUMENT_ROOT, or relative to the directory of the current file (which is not necessarily equivalent to the request URI, if the current file is included)? I managed to get my site to work using !--#include file-- and specifying full pathnames and using PerlSetVar IncludesDir, but it would have been nice if there was a way to include a file with relative path specifications as in the above paragraph (and still be in the same namespace). I first learned ASP on IIS, and there, !--#include virtual-- (which allows the relative path specifications) can be used for this purpose. -Philip Mak ([EMAIL PROTECTED]) On Sat, 20 May 2000, Joshua Chamas wrote: Ime Smits wrote: | Well, I would like to suggest that you consider including !--#include | virtual-- in the Apache::ASP distribution, so that included files use the | same namespace. It doesn't make sense logically that include virtual | behaves differently from include file (other than the way the | filename/pathname is interpreted, of course). It does make sense to me, though. Consider one having very big (say 50k) include files being included from several other (say 100) scripts. Just sucking them in each script doing the include would cause *every* script growing by at least the size of the include. Now as Apache::ASP caches all compiled scripts, this would result in each httpd process growing by 50kB x 100 scripts = 5 MB, holding 98% redundant data. If DynamicIncludes are turned on, then file includes are compiled as subroutines, and executed as if $Response-Include() were called. Without this setting, includes text are added to the including scripts like you are saying. But this does not solve the virtual includes problem. A virtual include is supposed to be anything executed on the server, not just files, but the output from anything like some C cgi, or another .pl or so, and must therefore be processed as a separate subrequest. This is what Apache::SSI does. The problem here is that there is no way for the Apache::ASP script to catch the output from the apache subrequest to even try to compile it into its own script, even if you really wanted to do this. So this is why this is stays a separate feature to be handled by Apache::SSI, that it doesn't help at all to inline it into Apache::ASP, except some small performance benefit by not running the output through Apache::Filter -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: mod_perl and BSDi 4.1
On Fri, 19 May 2000, Russell Hay wrote: BSDi/4.1 ... cannot find libperl.so. Find the directory on your machine with libperl.so in it (probably /usr/libdata/perl5/i386-bsdos/5.00402/CORE or /usr/local/lib/perl5/5.00502/i386-bsdos/CORE/), add it to /etc/ld.so.conf, and run ldconfig. - Matt
Re: Apache::ASP #include virtual loses variables
Philip Mak wrote: So, there's no way in Apache::ASP to include a file by specifying a path relative to DOCUMENT_ROOT, or relative to the directory of the current file (which is not necessarily equivalent to the request URI, if the current file is included)? I managed to get my site to work using !--#include file-- and specifying full pathnames and using PerlSetVar IncludesDir, but it would have been nice if there was a way to include a file with relative path !--#include file= -- allows relative file specifications. Did it not work for you for some reason? -- Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Apache::ASP #include file, relative filenames
On Sun, 21 May 2000, Joshua Chamas wrote: So, there's no way in Apache::ASP to include a file by specifying a path relative to DOCUMENT_ROOT, or relative to the directory of the current file (which is not necessarily equivalent to the request URI, if the current file is included)? !--#include file= -- allows relative file specifications. Did it not work for you for some reason? It does not work in this kind of situation: /series/slayers/lina/index.inc does !--#include file="../index.inc"-- /series/slayers/index.inc does !--#include file="../index.inc"-- If I access http://.../series/slayers/lina/index.inc, then it will do the first include correctly. But in the second include, it resolves the path name relative to /series/slayers/lina/ instead of /series/slayers/, so it ends up including /series/slayers/index.inc instead of /series/index.inc. I worked around this by doing "PerlSetVar IncludesDir /home/goamembers/www" (which is my DOCUMENT_ROOT), and then using includes such as: !--#include file="/series/slayers/index.inc"-- !--#include file="/series/slayers/lina/index.inc"-- -Philip Mak ([EMAIL PROTECTED])
Re: frontend proxy really useful?
Hi there, On Sat, 20 May 2000, Chris Nokleberg wrote: I was rereading http://perl.apache.org/guide/scenario.html#Buffering_Feature does it make the light frontend buffering proxy technique useless as long as your pages fit in the socket buffer size (256K on Solaris)? (assuming the proxy is just a dumb passthrough to one backend server) You might think that it serves little purpose for a light Apache server simply to pass all requests from a socket through to a heavy mod_perl server, only then to receive the reply and pass it back to the socket. But you don't usually know what is the other side of the socket, and so you don't know how fast the buffer will be emptied. It might take a couple of minutes if the client is on a slow line. Your processes could all be waiting for the socket buffers to be emptied by slow clients, so there may be no free child to serve an incoming request. In that case Apache will just keep spawning new ones (if it's allowed) for any new incoming requests. You could build up a big heap of waiting processes. You will have far less resources consumed by the waiting processes if they are plain Apache children than you will if they are Apache+mod_perl children. So you will be able to spawn more processes, and so serve more incoming requests. It depends of course on the profiles of your users, the resources requested, etc.etc... You can make measurements, or calculations, or guesses, or you can just wing it. But you don't want to let Apache spawn so many children that you get into swapping, nor do you want to force your clients to wait unnecessarily. 73, Ged.
Re: RFC: Apache::Request::Forms (or something similar)
On Fri, 19 May 2000, Doug MacEachern wrote:
'ref_array' = sub {
my @a;
push @a, \($one, $two, $three);
my_print(@a);
},
aha. i knew i wasn't on crack. i just forgot an important
detail ;)
Re: mod_perl and BSDi 4.1
"RH" == Russell Hay [EMAIL PROTECTED] writes: RH I am having a problem getting mod_perl to actually load under apache (as a RH DSO) on BSDi/4.1... it appears that (even though the file exists in the RH proper location) it cannot find libperl.so. I double/triple checked that Here's the mod_perl config I use under 4.0.1; it should work for 4.1 unless something drastic changed in the dynamic loader, which I doubt. save as makepl_args.mod_perl one level up from your mod_perl source directory. alter the modules listed as you see fit. Be sure you have mod_perl 1.24 which is the latest. # for Apache 1.3.6 and mod_perl 1.19+ # PERL_POST_READ_REQUEST=1 PERL_TIE_TABLES=1 PERL_SSI=1 # PERL_STACKED_HANDLERS=1 USE_APACI=1 EVERYTHING=1 USE_DSO=1 USE_APACI=1 APACI_ARGS=--with-layout=../apache-bsdi.layout:bsdi APACI_ARGS=--enable-module=all APACI_ARGS=--enable-shared=max #APACI_ARGS=--disable-shared=env APACI_ARGS=--disable-shared=log_config APACI_ARGS=--disable-shared=mime APACI_ARGS=--disable-shared=status APACI_ARGS=--disable-shared=info APACI_ARGS=--disable-shared=include APACI_ARGS=--disable-shared=dir #APACI_ARGS=--disable-shared=alias APACI_ARGS=--disable-shared=access APACI_ARGS=--disable-shared=auth APACI_ARGS=--disable-shared=setenvif # use apxs to compile mod_auth_mysql.c and mod_auth_cookie.c
Re: mod_perl and BSDi 4.1
"MC" == Matt Carothers [EMAIL PROTECTED] writes: MC On Fri, 19 May 2000, Russell Hay wrote: BSDi/4.1 ... cannot find libperl.so. MC Find the directory on your machine with libperl.so in it MC (probably /usr/libdata/perl5/i386-bsdos/5.00402/CORE or MC /usr/local/lib/perl5/5.00502/i386-bsdos/CORE/), add it to MC /etc/ld.so.conf, and run ldconfig. Shouldn't be necessary unless something drastic changed between BSD/OS 4.0.1 and 4.1 regarding the compiler and linker flags. I did plenty of work on mod_perl to make it compile and run out of the box on BSD/OS, but I have not tested on BSD/OS 4.1. The proper runtime locations for the .so file should get set during the compile.
Project Information
Good afternoon... My name is Allen Wilson and I am looking to join a mod-perl team. If there are any positions available on current projects, I would appreciate any information pertaining to the project and the available positions. Thank You. Allen J. Wilson Irving, Texas
Re: frontend proxy really useful?
On Sun, 21 May 2000, G.W. Haywood wrote: You might think that it serves little purpose for a light Apache server simply to pass all requests from a socket through to a heavy mod_perl server, only then to receive the reply and pass it back to the socket. But you don't usually know what is the other side of the socket, and so you don't know how fast the buffer will be emptied. It might take a couple of minutes if the client is on a slow line. Your processes could all be waiting for the socket buffers to be emptied by slow clients, so there may be no free child to serve an incoming request. In that case Apache will just keep spawning new ones (if it's allowed) for any new incoming requests. You could build up a big heap of waiting processes. You will have far less resources consumed by the waiting processes if they are plain Apache children than you will if they are Apache+mod_perl children. So you will be able to spawn more processes, and so serve more incoming requests. But the guide seems to be saying that the speed of the client isn't an issue--the process (proxy _or_ mod_perl) is released as soon as it finishes putting the outputted page into the OS socket buffer. I assume "released" means it can go and serve another request. Am I reading it wrong? "Therefore if you don't use mod_proxy and mod_perl send its data directly to the client, and you have a big socket buffer, the mod_perl process will be released as soon as the last chunk of data will enter the buffer. Just like with mod_proxy, OS will worry to complete the data transfer." Chris
modperl with stronghold install
I'm getting the follow error when trying to install modperl with stronghold. Does anyone have any idea what it could be? Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com In file included from ../../../include/ap_config.h:1013, from ../../../include/httpd.h:71, from php.h:94, from parse.c:126: /usr/include/regex.h:28: warning: `REG_EXTENDED' redefined ../../../include/hsregex.h:41: warning: this is the location of the previous definition /usr/include/regex.h:29: warning: `REG_NEWLINE' redefined ../../../include/hsregex.h:44: warning: this is the location of the previous definition /usr/include/regex.h:30: warning: `REG_ICASE' redefined ../../../include/hsregex.h:42: warning: this is the location of the previous definition /usr/include/regex.h:31: warning: `REG_NOSUB' redefined ../../../include/hsregex.h:43: warning: this is the location of the previous definition /usr/include/regex.h:45: warning: `REG_NOTBOL' redefined ../../../include/hsregex.h:74: warning: this is the location of the previous definition /usr/include/regex.h:46: warning: `REG_NOTEOL' redefined ../../../include/hsregex.h:75: warning: this is the location of the previous definition /usr/include/regex.h:52: warning: `REG_ECOLLATE' redefined ../../../include/hsregex.h:53: warning: this is the location of the previous definition /usr/include/regex.h:53: warning: `REG_EESCAPE' redefined ../../../include/hsregex.h:55: warning: this is the location of the previous definition /usr/include/regex.h:60: warning: `REG_ERANGE' redefined ../../../include/hsregex.h:61: warning: this is the location of the previous definition /usr/include/regex.h:61: warning: `REG_ESPACE' redefined ../../../include/hsregex.h:62: warning: this is the location of the previous definition /usr/include/regex.h:62: warning: `REG_BADRPT' redefined ../../../include/hsregex.h:63: warning: this is the location of the previous definition /usr/include/regex.h:63: warning: `REG_ECTYPE' redefined ../../../include/hsregex.h:54: warning: this is the location of the previous definition /usr/include/regex.h:64: warning: `REG_BADPAT' redefined ../../../include/hsregex.h:52: warning: this is the location of the previous definition /usr/include/regex.h:65: warning: `REG_BADBR' redefined ../../../include/hsregex.h:60: warning: this is the location of the previous definition In file included from ../../../include/ap_config.h:1013, from ../../../include/httpd.h:71, from php.h:94, from parse.c:126: /usr/include/regex.h:23: conflicting types for `regoff_t' ../../../include/hsregex.h:25: previous declaration of `regoff_t' /usr/include/regex.h:96: conflicting types for `regex_t' ../../../include/hsregex.h:31: previous declaration of `regex_t' /usr/include/regex.h:104: conflicting types for `regmatch_t' ../../../include/hsregex.h:35: previous declaration of `regmatch_t' /usr/include/regex.h:119: conflicting types for `regcomp' ../../../include/hsregex.h:39: previous declaration of `regcomp' /usr/include/regex.h:121: conflicting types for `regexec' ../../../include/hsregex.h:73: previous declaration of `regexec' /usr/include/regex.h:122: conflicting types for `regerror' ../../../include/hsregex.h:69: previous declaration of `regerror' /usr/include/regex.h:123: conflicting types for `regfree' ../../../include/hsregex.h:83: previous declaration of `regfree' make[2]: *** [parse.o] Error 1 make[1]: *** [subdirs] Error 2 make: *** [apache_httpd] Error 2
disconnect overloaded
RH Linux 2.0.34 Apache/1.3.12 ApacheDBI-0.87 DBI-1.13 mySQL 3.22.20a Any ideas why I'm getting this "disconnect (overloaded)" entry each time a page is loaded? The data is represented correctly on the webpage. I am the only person hitting this server. 8901 Apache::DBI need ping: yes 8901 Apache::DBI already connected to 'whitman:192.168.1.1userpasswordAutoCommit=1PrintError=1' 8901 Apache::DBI disconnect (overloaded) --James --- ASCII Ribbon campaign against HTML E-Mail / \
Re: frontend proxy really useful?
Hi again, On Sun, 21 May 2000, Chris Nokleberg wrote: On Sun, 21 May 2000, G.W. Haywood wrote: It might take a couple of minutes if the client is on a slow line. But the guide seems to be saying that the speed of the client isn't an issue--the process (proxy _or_ mod_perl) is released as soon as it finishes putting the outputted page into the OS socket buffer. I assume "released" means it can go and serve another request. Am I reading it wrong? No. But what happens if the socket is still full of data from the previous request when the child attached to that socket gets another request for another socket-buffer-full? That's when you run into the problem. 73, Ged.
Re: Apache::ASP #include file, relative filenames
Philip Mak wrote:
On Sun, 21 May 2000, Joshua Chamas wrote:
So, there's no way in Apache::ASP to include a file by specifying a path
relative to DOCUMENT_ROOT, or relative to the directory of the current
file (which is not necessarily equivalent to the request URI, if the
current file is included)?
!--#include file= -- allows relative file specifications.
Did it not work for you for some reason?
It does not work in this kind of situation:
/series/slayers/lina/index.inc does !--#include file="../index.inc"--
/series/slayers/index.inc does !--#include file="../index.inc"--
I see, yes this would not have worked, because Apache::ASP
does a chdir() to whereever the script is. So what you could
do might be to have a header.inc which does something like...
%
use File::Basename;
my $dirname = dirname($0);
$dirname =~ s|^$ENV{DOCUMENT_ROOT}/?||;
my $up = '';
for(split(/\//, $dirname)) {
$up .= '../';
my $include = $up.'index.inc';
if(-e $include) {
$Response-Include($include);
}
}
%
--Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
scalar(%hash) gives zero
My script has these lines in it, my %in; CGI::ReadParse(\%in); print scalar(%in); print %in; Then I run it under shell, bash$ ./myscript.pl foo=1 bar=2 It gives me 0foo1bar2 Can anyone explain why the "0" but not the bucket usage? Kenneth PS. I'm using 5.6.0 with mod_perl/1.22
cvs commit: modperl-site index.html
cholet 00/05/21 15:45:50 Modified:.index.html Log: typos Revision ChangesPath 1.57 +4 -4 modperl-site/index.html Index: index.html === RCS file: /home/cvs/modperl-site/index.html,v retrieving revision 1.56 retrieving revision 1.57 diff -u -r1.56 -r1.57 --- index.html2000/05/15 21:06:21 1.56 +++ index.html2000/05/21 22:45:49 1.57 @@ -380,7 +380,7 @@ hr width="40%" align="left" pa name="general-list"/a - bmod_perl mailing list/b is available for + The bmod_perl mailing list/b is available for mod_perl users and developers to share ideas, solve problems and discuss things related to mod_perl and the CODEApache::*/CODE modules. br @@ -456,8 +456,8 @@ hr width="40%" align="left" pa name="advocacy-list"/a - A mailing list for bmod_perl advocacy issues/b, discussions about site and - etc. + A mailing list for bmod_perl advocacy issues/b, + discussions about the site, etc. br The list address for posting is a href="mailto:[EMAIL PROTECTED]"[EMAIL PROTECTED]/a. @@ -720,7 +720,7 @@ /p p - Check out yet another syrvey by + Check out yet another survey by a href="http://www.e-softinc.com/survey/data/index.html" E-Soft /a. (Hint: click on "Apache Module Report")
