Re: mod_perl Guide Patch
At 16:19 15/10/2002, Per Einar Ellefsen wrote: At 13:07 25.10.2002, Lee Goddard wrote: Well, not really a patch but a tiny contribution to an excellent guide -- Mr Beckman, I hope this is of use: On/section: guide/performance.html#Using_1_Under_mod_perl_and_be Using $|=1 Under mod_perl and Better print() Techniques Whilst the code is correct, even if it does use CGI.pm..., It might be a good idea to mention that if an external file is pulled in by the header, it seems that it has to be loaded before any output occurs. My print_html_header methods have a flag which will cause SCRIPT src and relevant LINK href URIs to be parsed, loaded and included inline. Slow but better than a poke in the eye with a sharp stick. Hello Lee, I'm sorry, but I'm not sure I understand what you mean by an external file is pulled in by the header. I understand your example, but not its relation to the section you refer to. Could you give a code example or some more information? Hello - I may have unsub'd from the list by now, so would you mind cc'ing this for me if it doesn't get through and if you think it useful? So, I simply meant that if you are trying to get $|=1 type instant output and your HTML header pulls in other files -- using script type=text/pascal src=another.doc/script or link rel='stylesheet' type='text/css' href='outside.css'/ then you will not get the expected output instantly, but only after the whole document has loaded. I guess this is because the document will not be rendered until the browser (or let's face, the IE6) has received the external files and the whole BODY. If you trying sticking a CSS/script link in the $q-html_head call in the mod_perl Guide example, you should see what I mean. Took me hours to figure it out Cheers lee
Re: mod_perl Guide Patch
Hello Lee, So, I simply meant that if you are trying to get $|=1 type instant output and your HTML header pulls in other files -- using script type=text/pascal src=another.doc/script or link rel='stylesheet' type='text/css' href='outside.css'/ then you will not get the expected output instantly, but only after the whole document has loaded. I guess this is because the document will not be rendered until the browser (or let's face, the IE6) has received the external files and the whole BODY. If you trying sticking a CSS/script link in the $q-html_head call in the mod_perl Guide example, you should see what I mean. Sure, I understand what you mean now. I'll consider it for inclusion. Thank you for your contribution. -- Per Einar Ellefsen [EMAIL PROTECTED]
mod_perl Guide Patch
Well, not really a patch but a tiny contribution to an excellent guide -- Mr Beckman, I hope this is of use: On/section: guide/performance.html#Using_1_Under_mod_perl_and_be Using $|=1 Under mod_perl and Better print() Techniques Whilst the code is correct, even if it does use CGI.pm..., It might be a good idea to mention that if an external file is pulled in by the header, it seems that it has to be loaded before any output occurs. My print_html_header methods have a flag which will cause SCRIPT src and relevant LINK href URIs to be parsed, loaded and included inline. Slow but better than a poke in the eye with a sharp stick. Hope that helps lee
Re: mod_perl Guide Patch
At 13:07 25.10.2002, Lee Goddard wrote: Well, not really a patch but a tiny contribution to an excellent guide -- Mr Beckman, I hope this is of use: On/section: guide/performance.html#Using_1_Under_mod_perl_and_be Using $|=1 Under mod_perl and Better print() Techniques Whilst the code is correct, even if it does use CGI.pm..., It might be a good idea to mention that if an external file is pulled in by the header, it seems that it has to be loaded before any output occurs. My print_html_header methods have a flag which will cause SCRIPT src and relevant LINK href URIs to be parsed, loaded and included inline. Slow but better than a poke in the eye with a sharp stick. Hello Lee, I'm sorry, but I'm not sure I understand what you mean by an external file is pulled in by the header. I understand your example, but not its relation to the section you refer to. Could you give a code example or some more information? -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: guide pdf documentation
Thanks. I didn't see the [pdf] button! I tried cvs'ing the data and doing the build deal referenced on perl.apache.org, but I'm missing something as I get an error from DocSet/Util.pm. It's trying to load Template.pm on line 13, but I don't have a Template.pm on my system anywhere. Because you miss the prerequisites. Template Toolkit is one of them. You need to install DocSet which will tell you what the prerequisites are. I'll release it on CPAN shortly. Meanwhile you can grab it from here: http://apache.org/~stas/DocSet-0.14.tar.gz Umm, I did install DocSet. Otherwise, how could I have gotten an error from DocSet/Util.pm? It was late for me, perhaps I missed seeing some error message? I'll try it again when I have more time. Thanks. Regards, Rich
Getting to the Guide PDF on the new website
At 09:24 PM 7/13/2002, Stas Bekman wrote: Gunther Birznieks wrote: I agree! It is great work. It looks really slick. :) Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the latest guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. eh? what do you mean? it's all there, go to: http://perl.apache.org/docs/1.0/guide/index.html click on the pdf button in the right upper corner and you get this: http://perl.apache.org/docs/1.0/guide/guide.pdf Notice though, that parts non-specific to mod_perl 1.0 has now moved to http://perl.apache.org/docs/general/index.html Oh I see it does work. I suppose the PDF buttons on every page is what confused me though. So if you go to the front-page of the docs section, just the front-page gets generated in a PDF, if you go to a page within the guide, then just that section gets generated. The only PDF icon that actually generates a full guide (and it is inconsistent with what the rest of the website PDF icons do) is the actually guide.pdf. A constructive suggestion would be that the icon for PDF on the main guide page should explicitly say PDF of entire guide or something other than the simple PDF icons on all the other pages of the website. Or perhaps remove the PDF icons entirely off the rest of the website. After all, who really wants to generate a PDF of a single HTML page they already read? __ 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 __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
Re: Getting to the Guide PDF on the new website
Gunther Birznieks wrote: At 09:24 PM 7/13/2002, Stas Bekman wrote: Gunther Birznieks wrote: I agree! It is great work. It looks really slick. :) Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the latest guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. eh? what do you mean? it's all there, go to: http://perl.apache.org/docs/1.0/guide/index.html click on the pdf button in the right upper corner and you get this: http://perl.apache.org/docs/1.0/guide/guide.pdf Notice though, that parts non-specific to mod_perl 1.0 has now moved to http://perl.apache.org/docs/general/index.html Oh I see it does work. I suppose the PDF buttons on every page is what confused me though. So if you go to the front-page of the docs section, just the front-page gets generated in a PDF, if you go to a page within the guide, then just that section gets generated. The only PDF icon that actually generates a full guide (and it is inconsistent with what the rest of the website PDF icons do) is the actually guide.pdf. A constructive suggestion would be that the icon for PDF on the main guide page should explicitly say PDF of entire guide or something other than the simple PDF icons on all the other pages of the website. Or perhaps remove the PDF icons entirely off the rest of the website. After all, who really wants to generate a PDF of a single HTML page they already read? Well, if you don't want to read the PDF of a single page, that doesn't mean that others think the same. People like reading of the paper and not the screen. The new site is based on docsets stacking. Each root node includes chapters and other docsets. Each root node builds the pdf of all its immediate leaf nodes (chapters). Each leaf (chapter) builds a pdf of itself. Notice that root nodes do *not* include chapters included in the nested docsets, otherwise the very root pdf will be of 50MB in size. I don't really follow your confusion. If you read the chapter 'help' and you click on the pdf icon you get this chapter in pdf. if you are reading the index page and click on the pdf you get the whole thing. It's just more flexible now than it used to be. I guess the only confusion might be with docsets that include no chapters, but only other docsets, so if you click on the pdf icon at /docs/1.0/ you get an almost empty pdf. But I guess people will learn how things work and find the infrastructure useful. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
ANNOUNCE: mod_perl guide v1.32
This is probably the last announcement regarding the mod_perl guide's changes, because on the new mod_perl site all the changes are almost instant and the need for releases is pretty much not needed any more. Therefore remember to refer to the Changes file if you want to know what has changed since the last time you've read some docs. That said, there will be no more separate mod_perl_guide's releases on CPAN as they used to be, since the guide has now been merged into the mod_perl documentation. It's possible that we will start releasing the modperl-docs repository on CPAN instead. We will see. Meanwhile you can download and install locally the guide and the rest of the docs here: http://perl.apache.org/download/docs.html So here are the changes in the guide since Nov 15 2001: =head1 Jul 14 2002 ver 1.32 * snippets.pod: o new recipe: File Upload with Apache::Request [Rich Bowen] * cookbook o ported Passing Arguments to a SSI script from the modperl faq * method_handlers.pod o moved here from the faqs * databases.pod o correct the notes regarding Opening Connections With Different Parameters for Apache::DBI. Must localize local changes. * getwet.pod o a new chapter to get you started fast * porting.pod o add a new section Preventing Apache::Constants Stringification [Per Einar] o add a new section presenting a hackish solution for libraries collision, via do() or %INC mangling. o bring the warnings section up to date with perl 5.6 (Rafael Garcia-Suarez) o cover the 5.6's CHECK block in addition to INIT (Rafael Garcia-Suarez) * troubleshooting.pod o solution to the 'readdir()/opendir() not working' problem (Louis Semprini) o clearify how to solve the segfault problem caused by built-in mysql support in mod_php (Paul Buder) * modules.pod o extend on Apache::Filter (Per Einar Ellefsen) * config.pod o adopt sections from the modperl faq and rewrite the whole security configuration section o extended on method handlers (Per Einar Ellefsen) o show an example on how to load the mod_perl related config only when mod_perl is loaded (Rafael Garcia-Suarez) o More information about PerlSetEnv/PerlPassEnv/PerlSetupEnv w/ practical example[Per Einar] o Extend on PerlSetVar/PerlAddVar but more importantly, add information about subrequests w/ lookup_file and dir_config provided by Matt Sergeant in this thread: http://mathforum.org/epigone/modperl/praxdwumze [Per Einar] * debug.pod o extended on curinfo macro (Per Einar Ellefsen) * help.pod o chroot(1) urls o jail(8) urls (Andrew McNaughton) o link to the internal resources (Per Einar Ellefsen) * install.pod o James G Smith has uploaded his Apache Builder to CPAN, update the download links, to reflect this change. * performance.pod o add more benchmarking tools refs: HTTP::WebTest, HTTP::Monkeywrench, HTTP::TestEngine, HTTPD::Bench::ApacheBench o update the benchmark in the section Apache::args vs. Apache::Request::param vs. CGI::param using Apache::Request 1.0. o Update the documentation on Apache::SizeLimit and Apache::GTopLimit which now both sport the shared and unshared memory thresholds. o added a new section: Potential Drawbacks of Memory Sharing Restriction * intro o major additions to the introduction, including information about the C API and the Perl API and Apache::PerlRun, as well as some more corrections of links relative to the site. [Per Einar] * guide o most of the internal links were changed to use the whole title and not only first few words. The new build system support this. o The documents themselves are now referenced as guide::something, e.g. guide::modules, because now the guide is a part of a much bigger collection of the documents, which need to be fully qualified, so each document can link to other documents in different projects/subprojects. o added descriptions to all chapters (Per Einar Ellefsen) o The document structure has been reorganized and decentralized: some general chapters have left the Guide in favor of the General Documentation section, which is where you should look now for some of the sections that were earlier here [Thomas Klausner] * Minor corrections: o remove qw() or variables list in general::perl_reference (Tim Noll [EMAIL PROTECTED]) o install: (Per Einar Ellefsen [EMAIL PROTECTED], Karl Olson [EMAIL PROTECTED]) __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
the Guide
I recently downloaded the mod_perl Guide and tried to install it. Problem is that it would not install properly because the file: pod2hpp was missing. After trying other versions I kept getting the same error. Then I checked google.com. I am not the only one w/ this problem. I conclude that the guide is built from the PODs (Plain Old Documents). pod2hpp is thus needed to convert the pods to html. The online guide is no doubt created the same way. Wouldn't it thus be simpler and more convenient for 1st times like myself if the guide download were simply the already created html pages which appear online. Naturally they would be compressed. Then one would only have to uncompress them instead of building them. It's hard enough to install mod_perl itself. Why add an extra burden for the manual also. Thanks. John Kolvereid __ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/
Re: the Guide
Wouldn't it thus be simpler and more convenient for 1st times like myself if the guide download were simply the already created html pages which appear online. Frankly, hardly anyone does that. Most people refer to the guide on-line. I've used mod_perl for years, referred to the guide frequently, and never downloaded it. If you have to work over a slow link I can understand why you might want a local copy, but a quick wget command can mirror it all for you pretty easilly. People usually only download the CPAN package if they're planning to do some hacking on it. Mentioning the module dependency in the text next to the download link is probably a good idea, and offering a .tgz of all the generated HTML files as well as the PDF, but I think you may be the first to request such a thing. It's hard enough to install mod_perl itself. Why add an extra burden for the manual also. There is plenty of documentation on building and working with mod_perl included in the standard mod_perl package. The guide is in addition to that documentation. - Perrin
cvs commit: modperl-site/guide help.html
stas02/03/07 08:03:12 Modified:guidehelp.html Log: [EMAIL PROTECTED][EMAIL PROTECTED]/ Revision ChangesPath 1.33 +6 -6 modperl-site/guide/help.html Index: help.html === RCS file: /home/cvs/modperl-site/guide/help.html,v retrieving revision 1.32 retrieving revision 1.33 diff -u -r1.32 -r1.33 --- help.html 15 Nov 2001 09:04:50 - 1.32 +++ help.html 7 Mar 2002 16:03:12 - 1.33 @@ -261,14 +261,14 @@ The Apache/Perl mailing list EMis available for mod_perl users and developers to share ideas, solve problems and discuss things related to mod_perl and the Apache::* modules./EM To subscribe to this list, send email to A -HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A +HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A . To unsubscribe send email to A -HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A +HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A . P To subscribe to the digest list send email to A -HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A +HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A . P @@ -426,11 +426,11 @@ P To subscribe to this list, send email to A -HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A +HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A . To unsubscribe send email to A -HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A +HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A . Send email to A -HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A to post to +HREF=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/A to post to the list. P
Problem with exception handler in guide?
I am trying to get the exception class described in the guide to work, but am having
trouble with die returning the class incorrectly.
The example in the guide was:
die My::Exception-RetCode(code = 204);
The module code is at:
http://thingy.kcilink.com/modperlguide/perl/The_My_Exception_class_in_its_e.html
with two modifications (the last die in sub AUTOLOAD was changed to CORE::die to
prevent a perl warning message about it being ambiguous, and the missing semicolon at
the end of the first line package ... was added).
The following script code does not work
#-
use My::Exception;
eval {
die My::Exception-Return(code = abc);
};
if ($@) {
use Data::Dumper;
print Dumper($@);
}
#-
It generates the output:
#-
$VAR1 = bless( {
'text' = 'My::Exception',
'caller' = {
'line' = 19,
'filename' = 'My/Exception.pm',
'package' = 'My::Exception'
}
}, 'My::Exception::UnCaught' );
#-
with the class indicating that the exception was not caught. Tracing it in the
debugger shows that it executes My::Exception::die using My::Exception as the first
argument.
If I put parens around the argument to die, as follows, it works (calls AUTOLOAD first
then returns result of that as first argument to My::Exception::die), returning the
correctly classed object.
Code:
#-
use My::Exception;
eval {
die (My::Exception-Return(code = abc));
};
if ($@) {
use Data::Dumper;
print Dumper($@);
}
#-
Output:
#-
$VAR1 = bless( {
'caller' = {
'line' = 5,
'filename' = './exceptions2',
'package' = 'main'
},
'code' = 'abc'
}, 'My::Exception::Return' );
#-
It appears that - is too low a precedence. Is there a way around this without
requiring that parentheses be used around die's arguments? I'm running this under
perl5.6.0. Here is output of perl -V:
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.0, archname=i586-linux
uname='linux manson 2.4.0 #1 wed aug 2 20:22:26 gmt 2000 i686 unknown '
config_args='-ds -e -Dprefix=/usr -Di_db -Di_dbm -Di_ndbm -Di_gdbm'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='cc', optimize='-O2 -pipe', gccversion=2.95.2 19991024 (release)
cppflags='-fno-strict-aliasing -I/usr/local/include'
ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -ldl -lm -lc -lcrypt
libc=, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
Built under linux
Compiled at Jan 19 2001 05:42:10
%ENV:
PERL5LIB=/home/mpressly/development/library
@INC:
/home/mpressly/development/library
/usr/lib/perl5/5.6.0/i586-linux
/usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i586-linux
/usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl
.
Matthew Pressly
cvs commit: modperl-site/guide install.html
stas01/12/20 23:43:38 Modified:guideinstall.html Log: s|www.perl.com/CPAN-local|www.cpan.org|g as the later doesn't feature multiplexing Revision ChangesPath 1.23 +1 -1 modperl-site/guide/install.html Index: install.html === RCS file: /home/cvs/modperl-site/guide/install.html,v retrieving revision 1.22 retrieving revision 1.23 diff -u -r1.22 -r1.23 --- install.html 2001/11/15 09:04:50 1.22 +++ install.html 2001/12/21 07:43:38 1.23 @@ -3674,7 +3674,7 @@ td pre Running make for DOUGM/mod_perl-x.xx.tar.gz Fetching with LWP: - A HREF=http://www.perl.com/CPAN-local/authors/id/DOUGM/mod_perl-x.xx.tar.gz;http://www.perl.com/CPAN-local/authors/id/DOUGM/mod_perl-x.xx.tar.gz/A + A HREF=http://www.cpan.org/authors/id/DOUGM/mod_perl-x.xx.tar.gz;http://www.cpan.org/authors/id/DOUGM/mod_perl-x.xx.tar.gz/A CPAN.pm: Going to build DOUGM/mod_perl-x.xx.tar.gz
ANNOUNCE: mod_perl guide ver. 1.31
A new version of the mod_perl guide is now available: - online: o HTML http://perl.apache.org/guide/ o PDF http://perl.apache.org/guide/mod_perl_guide.pdf.gz (665pp) - the source at CPAN: file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.31.tar.gz size: 472182 bytes md5: 72d698b0799d32c1c5b2f07cd1f75eb3 (it'll take a few hours for CPAN mirrors to catch up) Changes since v1.30: * intro.pod: o updated the long due credits section (~200 contributors! in total) * install.pod: o add When DSO can be Used (Doug) * modules.pod: o add Module::Use o add Apache::ConfigFile * debug.pod: o noted the fact that the technique of detecting aborted connections doesn't work with mod_proxy. * performance.pod: o removed from the last section a dead link of http://members.nbci.com/Alex_Maranda/gnuintel/GNUintel.htm * snippets.pod: o detecting SSL connection (Vivek Khera, Geoff Young, Issac Goldstand) o Note the Apache::Request-instance class method in addition to the POST2GET example (Robin Bjorn) * porting.pod: o s/headers_out/header_out/ where it was incorrectly used, (Issac Goldstand) o fix the potential bug when using -r $file followed by -M _ and 'do $filename' inbetween, which may call stat() and _ won't include the right stat struct. (Randy Kobes) * troubleshooting.pod: o SegFaults During Startup * help.pod: o add a reference to http://lists.perl.org/ o add references to the new mailing lists * code: o the results in lwp-bench.pl are correctly based on the number of @urls used (Boris Zentner) * strategy.pod: o new section: Closing Lingering Connections with Lingerd enjoy! _ 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: piece of code in mod_perl guide
pascal barbedor wrote:
[ ]
config.pm file
-
package AFPA::Evolif::Config ;
use XML::LibXML () ;
use XML::LibXSLT () ;
use XML::XPath () ;
use XML::Simple () ;
use DBI () ;
[ ... ]
Hi,
Could it be that XML::XPath does file tests on the
file $xmlfile passed to it through
XML::XPath-new(filename = $xmlfile)
which would cause '_' to use the stat on $xmlfile, rather
than the original config file?
best regards,
randy kobes
oh yes, this was the answer ! XML::XPATh-new stats the file.
thanks for clearing it out !
then maybe the last line of reread_conf in mod_perl guide should be
modified to
$MODIFIED{$file} = -M $file;
in case the do ( ) loads something which can possibily stat file.
ok, I'll add a note, saying that _ shouldn't be used if it's not known whether no
other files are stat'ed in between. Or even the other way around, so the default will
be -M $file
Good catch, Randy!
--
_
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: piece of code in mod_perl guide
Stas Bekman wrote:
pascal barbedor wrote:
[ ]
config.pm file
-
package AFPA::Evolif::Config ;
use XML::LibXML () ;
use XML::LibXSLT () ;
use XML::XPath () ;
use XML::Simple () ;
use DBI () ;
[ ... ]
Hi,
Could it be that XML::XPath does file tests on the
file $xmlfile passed to it through
XML::XPath-new(filename = $xmlfile)
which would cause '_' to use the stat on $xmlfile, rather
than the original config file?
best regards,
randy kobes
oh yes, this was the answer ! XML::XPATh-new stats the file.
thanks for clearing it out !
then maybe the last line of reread_conf in mod_perl guide should be
modified to
$MODIFIED{$file} = -M $file;
in case the do ( ) loads something which can possibily stat file.
ok, I'll add a note, saying that _ shouldn't be used if it's not known
whether no other files are stat'ed in between. Or even the other way
around, so the default will be -M $file
At the end I've just cached the value of -M, and saved an otherwise
needed stat() syscall :)
use vars qw(%MODIFIED);
sub reread_conf{
my $file = shift;
return unless defined $file;
return unless -e $file and -r _;
my $mod = -M _;
unless (exists $MODIFIED{$file} and $MODIFIED{$file} == $mod){
my $result;
unless ($result = do $file) {
warn couldn't parse $file: $@ if $@;
warn couldn't do $file: $!unless defined $result;
warn couldn't run $file unless $result;
}
$MODIFIED{$file} = $mod; # Update the MODIFICATION times
}
} # end of reread_conf
--
_
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: piece of code in mod_perl guide
pascal barbedor wrote:
hello,
I am reading mod_perl guide and i had a problem with a piece of code in
chapter 9.7.4.2 about
reloading configuration files. this is version jan 2001 but i have
checked in the last one the piece of code is the same.
when running the code exactly, things don't work, even outside mod_perl
environnment.
the sub below print file is different even though I don't change the file.
I have located that if i change $MODIFIED{$file} = -M _; to an
explicit $MODIFIED{$file} = -M $file;
That's weird. _ uses the cached stat's output from the last stat call.
Does this work for you?
perl -e '-s /etc/passwd; print -M _'
use some existing file of course.
in the last line, everything works fine.
since i do no test on any other file and I have understood that _
account s for the last file tested, I don't understand why it does work.
I am on NT4 perl 5.6.1
try it yourself ! so strange !
thanks for any explanation
*
for (1..10){
reread_conf(l:/asperl/site/lib/afpa/evolif/config.pm);
sleep 2;
}
our %MODIFIED;
sub reread_conf{
my $file=shift;
return unless $file;
return unless -e $file and -r _;
if ($MODIFIED{$file} and $MODIFIED{$file}== -M _){
print same ; }else {print different;}
print \n;
unless ($MODIFIED{$file} and $MODIFIED{$file}== -M _){
unless (my $result = do $file) {
warn ...
}
print \nmod:,$MODIFIED{$file},' :', -M _,\n;
$MODIFIED{$file} = -M _;
}
}
--
_
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: piece of code in mod_perl guide
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: pascal barbedor [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, October 07, 2001 2:22 PM
Subject: Re: piece of code in mod_perl guide
I have located that if i change $MODIFIED{$file} = -M _; to an
explicit $MODIFIED{$file} = -M $file;
That's weird. _ uses the cached stat's output from the last stat call.
Does this work for you?
perl -e '-s /etc/passwd; print -M _'
yes it works, but the piece of code in mod_perl guide does not work, on my
specific config.pm, I don't understand why.
see below, the code, the output of the code, the config file .
In fact, it looks like when I try it on any other file that my config file,
it works. or it works on my config file with the explicit -M $file instead
of -M _.
If you can find any explanation...
pascal barbedor
code run
: --
--
print -s 'l:/config.pm',\n, -M _,\n;
for (1..10){ reread_conf(l:/config.pm) }
our %MODIFIED;
sub reread_conf{
my $file=shift;
return unless $file;
return unless -e $file and -r _;
if ($MODIFIED{$file} and $MODIFIED{$file}== -M _){
print same } else { print different }
print \n;
unless ($MODIFIED{$file} and $MODIFIED{$file}== -M _){
unless (my $result = do $file){
print lecture\n;
warn lecture de $file impossible: $@ if $@;
warn do de $file impossible: $! unless defined $result;
warn run de $file impossible unless $result;
}
print \nmod:,$MODIFIED{$file},' :', -M _,\n;
$MODIFIED{$file} = -M _;
}
}
---
output of code (see that the first stat worked and gives an age of very few
fraction of days, where reread_conf gives 66 days.)
with -M _ last line
983
0.00259259259259259
different
mod: :
different
mod: :67.2868981481481
different
mod:67.2868981481481 :67.2868981481481
different
mod:67.2868981481481 :67.2868981481481
different
mod:67.2868981481481 :67.2868981481481
different
mod:67.2868981481481 :67.2868981481481
different
mod:67.2868981481481 :67.2868981481481
different
mod:67.2868981481481 :67.2868981481481
different
mod:67.2868981481481 :67.2868981481481
different
mod:67.2868981481481 :67.2868981481481
Bonne exécution du processus
-
output of code with -M $file last line
983
0.0047337962962963
different
mod: :
same
same
same
same
same
same
same
same
same
Bonne exécution du processus
--
config.pm file
package AFPA::Evolif::Config ;
use XML::LibXML () ;
use XML::LibXSLT () ;
use XML::XPath () ;
use XML::Simple () ;
use DBI () ;
my $base='l:/perlinclude';
$CHASH{pconn}-disconnect() if $CHASH{pconn};
our %CHASH = (
indicateurs =
XML::LibXML-new-parse_file('l:/perlinclude/indicateurs.xml')
,
glups =
XML::LibXSLT-new-parse_stylesheet
(XML::LibXML-new-parse_file(l:/perlinclude/glups.xsl))
,
groupes =XML::XPath-
new(filename=l:/perlinclude/categories/groupements.xml)
,
zones =XML::XPath-
new(filename=l:/perlinclude/categories/decoupages.xml)
,
select=XML::LibXSLT-new-parse_stylesheet
(XML::LibXML-new-parse_file(l:/perlinclude/evselecteur.xsl))
,
pconn=DBI-connect(DBI:mysql:database=evolif;host=localhost,
pconn,
undef,
{RaiseError=1}
)
,
) ;
#my $stylesheet=
# XML::LibXSLT-new-parse_stylesheet (F_GLUP_XML);
#print $stylesheet-transform(F_IND_XML);
1 ;
Re: piece of code in mod_perl guide
[ ]
config.pm file
-
package AFPA::Evolif::Config ;
use XML::LibXML () ;
use XML::LibXSLT () ;
use XML::XPath () ;
use XML::Simple () ;
use DBI () ;
[ ... ]
Hi,
Could it be that XML::XPath does file tests on the
file $xmlfile passed to it through
XML::XPath-new(filename = $xmlfile)
which would cause '_' to use the stat on $xmlfile, rather
than the original config file?
best regards,
randy kobes
oh yes, this was the answer ! XML::XPATh-new stats the file.
thanks for clearing it out !
then maybe the last line of reread_conf in mod_perl guide should be
modified to
$MODIFIED{$file} = -M $file;
in case the do ( ) loads something which can possibily stat file.
pascal barbedor
sub reread_conf{
my $file=shift;
return unless $file;
return unless -e $file and -r _;
unless ($MODIFIED{$file} and $MODIFIED{$file}== -M _){
unless (my $result = do $file){
print lecture\n;
warn lecture de $file impossible: $@ if $@;
warn do de $file impossible: $! unless defined $result;
warn run de $file impossible unless $result;
}
$MODIFIED{$file} = -M _
}
}
piece of code in mod_perl guide
hello,
I am reading mod_perl guide and i had a problem
with a piece of code in chapter 9.7.4.2 about
reloading configuration files. this is version jan
2001 but i have checked in the last one the piece of code is the
same.
when running the code exactly, things don't work,
even outside mod_perl environnment.
the sub below print file is different even
though I don't change the file.
I have located that if i change$MODIFIED{$file} = -M _;
to an explicit$MODIFIED{$file} = -M
$file;
in the last line, everything works
fine.
since i do no test on any other file and I have
understood that _ account s for the last file tested, I don't understand why it
does work.
I am on NT4 perl 5.6.1
try it yourself ! so strange !
thanks for any explanation
*
for (1..10){
reread_conf("l:/asperl/site/lib/afpa/evolif/config.pm");
sleep 2;
}
our %MODIFIED;
sub reread_conf{
my $file=shift;
return unless $file;
return unless -e $file and -r _;
if ($MODIFIED{$file} and $MODIFIED{$file}==
-M _){
print "same" ; }else {print
"different";}
print "\n";
unless ($MODIFIED{$file} and
$MODIFIED{$file}== -M _){
unless (my $result = do $file) {
warn ...
}
print "\nmod:",$MODIFIED{$file},'
:', -M _,"\n";
$MODIFIED{$file} = -M
_;
}
}
[Somewhat OT] Typo in the guide
I actually tried to send this directly to Sats - twice. But mail seemed to be bouncing, so I suppose I'll have to do this through the list... Firstly - the typo: the mod_perl porting page contains info about setting HTTP headers - but the guide says to do $r-headers_out, when the function is $r-header_out (w/o the s). This might also be in the book, which brings me to issue #2: I recently lost my bookmarks, can you please resend the URL to the book - I remember my user/pass (I think so, anyway), but need the URL Thanks, Issac PS. Stas: I think mail bounced because you (or some RBL you use) blacklisted my ISP. The error was "Service unavailable (554 m1.bezeqint.net[192.115.106.45]: Client host rejected: Access denied)" Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: mod_proxy and mod_perl in guide
These are protected files so we have to use authentication and authorization that is done by mod_perl. And Internet Explorer that use most of our customers has bug that prevents displaying of PDF (and any other large non-dynamic non-HTML) files if the URL to that file was result of Redirect. Thanks for help. Andrei On Mon, Sep 17, 2001 at 08:55:03AM -0700, ed phillips wrote: Thanks Vivek, Andrei, use the front end to directly handle any binaries, static files, etc. I doubt they are generating of these on the fly. Vivek Khera wrote: AAV == Andrei A Voropaev [EMAIL PROTECTED] writes: AAV In our system we have to pass large PDF files thru mod_perl to AAV proxy and we noticed that it takes the same time as sending it AAV directly to customer. Why do you have to pass the PDF thru mod_perl? Are you generating it on the fly? If not, configure your proxy front end to intercept static documents like .pdf .txt .html etc. to be handled by the front end directly. I use mod_rewrite for this, and my configs have been posted to this list at least twice. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
mod_proxy and mod_perl in guide
Hi! I have one question. According to the Guide there's buffering feature of mod_proxy that allows to release heavy mod_perl process from delivering data over slow connection to the user. In our system we have to pass large PDF files thru mod_perl to proxy and we noticed that it takes the same time as sending it directly to customer. After checking Apache code for mod_proxy looks like it is normal behaviour. File modules/proxy/proxy_util.c function ap_proxy_send_fb. This function reads from originating server into buffer and then writes to the customer from this buffer. BUT the socket is closed AFTER all the data is sent to the client (file module/proxy/proxy_http.c function ap_proxy_http_handler. So the heavy mod_perl server is not released for serving other requests untill the data is sent to the client by proxy. Maybe I'm missing something but the practice shows that this is true and Guide contains error. Please someone check this. Thank you Andrei
Re: mod_proxy and mod_perl in guide
After checking Apache code for mod_proxy looks like it is normal behaviour. File modules/proxy/proxy_util.c function ap_proxy_send_fb. This function reads from originating server into buffer and then writes to the customer from this buffer. BUT the socket is closed AFTER all the data is sent to the client (file module/proxy/proxy_http.c function ap_proxy_http_handler. So the heavy mod_perl server is not released for serving other requests untill the data is sent to the client by proxy. Maybe I'm missing something but the practice shows that this is true and Guide contains error. Maybe the thing you're missing is that mod_proxy takes care of the lingering close. Those of us who have tried the two-server setup have all seen dramatic reductions in the number of mod_perl processes required. - Perrin
Re: mod_proxy and mod_perl in guide
AAV == Andrei A Voropaev [EMAIL PROTECTED] writes: AAV In our system we have to pass large PDF files thru mod_perl to AAV proxy and we noticed that it takes the same time as sending it AAV directly to customer. Why do you have to pass the PDF thru mod_perl? Are you generating it on the fly? If not, configure your proxy front end to intercept static documents like .pdf .txt .html etc. to be handled by the front end directly. I use mod_rewrite for this, and my configs have been posted to this list at least twice. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: mod_proxy and mod_perl in guide
Thanks Vivek, Andrei, use the front end to directly handle any binaries, static files, etc. I doubt they are generating of these on the fly. Vivek Khera wrote: AAV == Andrei A Voropaev [EMAIL PROTECTED] writes: AAV In our system we have to pass large PDF files thru mod_perl to AAV proxy and we noticed that it takes the same time as sending it AAV directly to customer. Why do you have to pass the PDF thru mod_perl? Are you generating it on the fly? If not, configure your proxy front end to intercept static documents like .pdf .txt .html etc. to be handled by the front end directly. I use mod_rewrite for this, and my configs have been posted to this list at least twice. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: [ANNOUNCE] Perl Templating Guide, v 0.9
On Wed, Aug 01, 2001 at 12:15:53AM -0700, Perrin Harkins wrote:
http://perl.apache.org/features/tmpl-cmp.html
The article Choosing a Templating System is now available at the above
URL. This is the same material I presented at the O'Reilly conference,
but a bit less rushed. It gives an overview of currently available
templating tools and their basic features.
This version is bound to have some bugs and general foolishness in it,
so please send me an e-mail if you spot anything.
only flaw i saw was it's (it is) that shoulda been its (his,
hers, its):
HTML::Mason ...but has since become it's own unique animal...
s/'//
nice job! very informative. i feel better about using mason, and
still i wanna learn about axkit. :)
--
Khan said that revenge is a dish best served cold. I think
sometimes it's best served hot, chunky, and foaming.
- P.J.Lee ('79-'80)
[EMAIL PROTECTED]
http://sourceforge.net/projects/newbiedoc -- we need your brain!
http://www.dontUthink.com/ -- your brain needs us!
Re: mod_perl guide HELP -- Full transcript
[Moving the discussion where it belongs to: the mod_perl list] On Fri, 3 Aug 2001, christopher sagayam wrote: please ignore if my earlier email was clear enough what's the value of PERL and FULLPERL var in the generated Makefile? e.g. on my machine: PERL = /usr/bin/perl FULLPERL = /usr/bin/perl if it's not /tmp/chrisperl/bin/perl than you have an issue with Perl, and not mod_perl. # /tmp/chrisperl/bin/perl Makefile.PL Configure mod_perl with ../apache_1.3.20/src ? [y] y Shall I build httpd in ../apache_1.3.20/src for you? [y] y Appending mod_perl to src/Configuration Using config file: /tmp/dump/mod_perl-1.26/src/Configuration Creating Makefile + configured for Solaris 280 platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.26 + id: Perl/5.00503 (solaris) [perl] chris - Original Message - From: christopher sagayam [EMAIL PROTECTED] To: Stas Bekman [EMAIL PROTECTED] Sent: Friday, August 03, 2001 11:19 AM Subject: Re: mod_perl guide HELP Thanks a lot for your response but what happens is when it reports + adding selected modules o perl_module uses ConfigStart/End + mod_perl build type: OBJ + setting up mod_perl build environment + id: mod_perl/1.26 + id: Perl/5.00503 (solaris) [perl] it reports the old version namely 5.00503 whereas the new perl is version 5.6 # /tmp/chrisperl/bin/perl -v This is perl, v5.6.1 built for sun4-solaris Copyright 1987-2001, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using `man perl' or `perldoc perl'. If you have access to the Internet, point your browser at http://www.perl.com/, the Perl Home Page. please help again ? Thanks chris - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: christopher sagayam [EMAIL PROTECTED] Sent: Friday, August 03, 2001 11:09 AM Subject: Re: mod_perl guide HELP yOn Fri, 3 Aug 2001, christopher sagayam wrote: I want the modperl and apache installation to recognize the perl installed at /tmp/newperl/bin/perl and not the default /usr/bin/perl so what configuration parameteres i must pass to perl Makefile.PL You should build mod_perl with your other Perl % /tmp/newperl/bin/perl Makefile.PL ... _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
[ANNOUNCE] Perl Templating Guide, v 0.9
http://perl.apache.org/features/tmpl-cmp.html The article Choosing a Templating System is now available at the above URL. This is the same material I presented at the O'Reilly conference, but a bit less rushed. It gives an overview of currently available templating tools and their basic features. This version is bound to have some bugs and general foolishness in it, so please send me an e-mail if you spot anything. Some ideas for future versions: - Code sample for each system - Links to other articles for each system - More complete benchmark information - Recommended practices for using templates in general Slouching towards 1.0, Perrin
Re: cvs commit: modperl-site/guide download.html
--On 17/07/01 15:16 + [EMAIL PROTECTED] wrote: sbekman 01/07/17 08:16:44 Modified:.distributions.html index.html mod_perl_cvs.html dist .htaccess embperl CVS.pod.1.html guidedownload.html Log: - cvs server has been moved. - /from-cvs has been moved. $ grep -lr from-cvs . | xargs perl -pi -e \ 's|/dev\.apache\.org/from-cvs|cvs.apache.org/snapshots|g' $ grep -lr from-cvs . | xargs perl -pi -e \ 's|/perl\.apache\.org/from-cvs|cvs.apache.org/snapshots|g' your substitution is missing a leading slash, therefore you just turned http:// into http:/ Revision ChangesPath 1.13 +2 -2 modperl-site/distributions.html Index: distributions.html === RCS file: /home/cvs/modperl-site/distributions.html,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- distributions.html 2001/06/10 04:55:43 1.12 +++ distributions.html 2001/07/17 15:16:00 1.13 @@ -14,8 +14,8 @@ LIMaster Source distribution - Release A HREF=http://perl.apache.org/dist; http://perl.apache.org/dist /A, the latest CVS snapshot -A HREF=http://perl.apache.org/from-cvs/; -http://perl.apache.org/from-cvs//A +A HREF=http:/cvs.apache.org/snapshots/ +http:/cvs.apache.org/snapshots//A /LI LI Win32 mod_perl Binaries (made by Randy Kobes) - A 1.82 +1 -1 modperl-site/index.html Index: index.html === RCS file: /home/cvs/modperl-site/index.html,v retrieving revision 1.81 retrieving revision 1.82 diff -u -r1.81 -r1.82 --- index.html 2001/06/24 07:28:19 1.81 +++ index.html 2001/07/17 15:16:03 1.82 @@ -172,7 +172,7 @@ p The latest development a href=mod_perl_cvs.htmlCVS snapshot/a is available from A - HREF=http://perl.apache.org/from-cvs/modperl/;here/A + HREF=http:/cvs.apache.org/snapshots/modperl/here/A (updated every 6 hours) for those who want to live on the edge. /p 1.5 +3 -3 modperl-site/mod_perl_cvs.html Index: mod_perl_cvs.html === RCS file: /home/cvs/modperl-site/mod_perl_cvs.html,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- mod_perl_cvs.html 2000/03/16 20:18:59 1.4 +++ mod_perl_cvs.html 2001/07/17 15:16:05 1.5 @@ -115,13 +115,13 @@ HREF=http://dev.apache.org/anoncvs.txt;http://dev.apache.org/anoncvs .txt/A -DTSTRONGA NAME=item_fromfrom-cvs/A/STRONGDD +DTSTRONGA NAME=item_fromsnapshots/A/STRONGDD P A snapshot is rolled of the modperl tree every 6 hours and placed here: P A -HREF=http://perl.apache.org/from-cvs/modperl/;http://perl.apache.org /from-cvs/modperl//A +HREF=http:/cvs.apache.org/snapshots/modperl/http:/cvs.apache.org/sn apshots/modperl//A P @@ -130,7 +130,7 @@ P A -HREF=http://perl.apache.org/from-cvs/;http://perl.apache.org/from-cv s//A +HREF=http:/cvs.apache.org/snapshots/http:/cvs.apache.org/snapshots/ /A /DL 1.2 +1 -1 modperl-site/dist/.htaccess Index: .htaccess === RCS file: /home/cvs/modperl-site/dist/.htaccess,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- .htaccess 1998/04/26 09:34:38 1.1 +++ .htaccess 2001/07/17 15:16:19 1.2 @@ -1 +1 @@ -Redirect /dist/CVS http://dev.apache.org/from-cvs/modperl +Redirect /dist/CVS http:/cvs.apache.org/snapshots/modperl 1.19 +3 -3 modperl-site/embperl/CVS.pod.1.html Index: CVS.pod.1.html === RCS file: /home/cvs/modperl-site/embperl/CVS.pod.1.html,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- CVS.pod.1.html 2001/02/12 09:18:34 1.18 +++ CVS.pod.1.html 2001/07/17 15:16:26 1.19 @@ -137,7 +137,7 @@ P A -HREF=http://perl.apache.org/from-cvs/embperl/;http://perl.apache.org /from-cvs/embperl//A +HREF=http:/cvs.apache.org/snapshots/embperl/http:/cvs.apache.org/sn apshots/embperl//A P @@ -146,14 +146,14 @@ P A -HREF=http://dev.apache.org/from-cvs/;http://dev.apache.org/from-cvs/ /A +HREF=http:/cvs.apache.org/snapshots/http:/cvs.apache.org/snapshots/ /A P and mod_perl can be found here P A -HREF=http://perl.apache.org/from-cvs/modperl/;http://perl.apache.org /from-cvs/modperl//A +HREF=http:/cvs.apache.org/snapshots/modperl/http:/cvs.apache.org/sn apshots/modperl//A P 1.17 +2 -2
ANNOUNCE: mod_perl guide ver. 1.29
The updated guide is out, rush and read it before you ask a question :) How to get it: * CPAN: file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.29.tar.gz size: 469832 bytes md5: 498ae2164b637f59bea34cbe9343b9ac * Online: http://perl.apache.org/guide/ * PDF Book (663pp) http://perl.apache.org/guide/mod_perl_guide.pdf.gz === Changes: 04.26.2001 ver 1.29 * dbm.pod: o updated Flawed Locking Methods Which Must Not Be Used with notes about lock upgrading (David Harris) * strategy.pod: o added a ref to a light and fast Boa webserver * scenario.pod: o cleared out the section on open proxying with mod_proxy (Eric Cholet) * multiuser.pod: o extended the Virtual Servers Technologies section with freevsd, freevmware, vmware and S/390 references. * snippets.pod: o removed the cache control section -- it's covered in the HTTP headers chapter. o subrequests and notes working together (Darren Chamberlain) * performance.pod: o Interpolation vs List update: wrongly used the 'concatenation' term instead of interpolation (Mark Summerfield) o Interpolation, Concatenation or List was rewritten o new: Architecture Specific Compile Options (Tim Bunce, Perrin Harkins, Greg Cope, Owen Williams, Vivek Khera, Steve Fink, James W Walden) * modules.pod: o Extended the docs of Apache::SubProcess module * porting.pod: o using register_cleanup in startup.pl to register cleanup action at the server shutdown or restart (Doug) * config.pod: o Cleared the item which was falsely stating that the globals defined in startup.pl cannot be seen by child process. (Richard Chen) * install.pod: o updated Discovering Whether Some Option Was Configured: added Apache::MyConfig o debian/apt install notes updates (Neil Conway) o some callback hooks aren't enabled by ALL_HOOKS=1 (Neil Conway) * download.pod o update the location of mod_proxy_add_forward.c (Ask Bjorn Hansen) * help.pod o added a link to Andrew Ford's Apache and mod_perl pocket books. o added a link to take23.org o added a XS resources section o added a link to the scalable list archive o remove the mailing list post address, to make it easier of Ask to filter SPAM. * troubleshooting.pod o new: exit signal Segmentation fault (11) with mysql: (Matt Sergeant) o improved the docs of fixing a broken /dev/null * debug.pod o updated gdb says there are no debugging symbols -- a simpler technique to have the binary unstripped during make install. * Minor corrections: o debug.pod (Alexander Farber) o performance.pod (Marc Lehmann, Kees Vonk) o snippets.pod (Ime Smits) o porting.pod (Michele Beltrame) o config.pod (Surat Singh Bhati, Paul Cotter ) o control.pod (Aaron Johnson, Cliff Rayman, Yann Kerherv) o modules.pod (Daniel Bohling) o install.pod (Kevin Swope, Jamie) Enjoy! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
thttpd v.s. boa (Re: ANNOUNCE: mod_perl guide ver. 1.29)
On Sat, 28 Apr 2001, Stas Bekman wrote: * strategy.pod: o added a ref to a light and fast Boa webserver The strategy guide mentions thttpd, khttpd and Boa. khttpd doesn't look to be production quality yet (its website says that it can crash the kernel), so that leaves thttpd and Boa. Which one would be better to use? Here's what I know so far: - Someone's reported thttpd using over 100 MB of memory, and suggested to switch to Boa instead. (the message is in the thttpd mailing list archives somewhere... February 2001 I think) - thttpd's website shows benchmarks where thttpd handles 720 requests per second, while Boa only handles 475. - thttpd supports chroot and throttling. Boa does not. -Philip Mak ([EMAIL PROTECTED])
cvs commit: modperl-site/guide CHANGES browserbugs.html config.html control.html correct_headers.html dbm.html debug.html download.html help.html index.html index_long.html install.html intro.html mod_perl_guide.pdf.gz modules.html multiuser.html performance.html perl.html porting.html scenario.html snippets.html start.html strategy.html troubleshooting.html
sbekman 01/04/27 09:57:30 Modified:guideCHANGES browserbugs.html config.html control.html correct_headers.html dbm.html debug.html download.html help.html index.html index_long.html install.html intro.html mod_perl_guide.pdf.gz modules.html multiuser.html performance.html perl.html porting.html scenario.html snippets.html start.html strategy.html troubleshooting.html Log: * dbm.pod: o updated Flawed Locking Methods Which Must Not Be Used with notes about lock upgrading (David Harris) * strategy.pod: o added a ref to a light and fast Boa webserver * scenario.pod: o cleared out the section on open proxying with mod_proxy (Eric Cholet) * multiuser.pod: o extended the Virtual Servers Technologies section with freevsd, freevmware, vmware and S/390 references. * snippets.pod: o removed the cache control section -- it's covered in the HTTP headers chapter. o subrequests and notes working together (Darren Chamberlain) * performance.pod: o Interpolation vs List update: wrongly used the 'concatenation' term instead of interpolation (Mark Summerfield) o Interpolation, Concatenation or List was rewritten o new: Architecture Specific Compile Options (Tim Bunce, Perrin Harkins, Greg Cope, Owen Williams, Vivek Khera, Steve Fink, James W Walden) * modules.pod: o Extended the docs of Apache::SubProcess module * porting.pod: o using register_cleanup in startup.pl to register cleanup action at the server shutdown or restart (Doug) * config.pod: o Cleared the item which was falsely stating that the globals defined in startup.pl cannot be seen by child process. (Richard Chen) * install.pod: o updated Discovering Whether Some Option Was Configured: added Apache::MyConfig o debian/apt install notes updates (Neil Conway) o some callback hooks aren't enabled by ALL_HOOKS=1 (Neil Conway) * download.pod o update the location of mod_proxy_add_forward.c (Ask Bjorn Hansen) * help.pod o added a link to Andrew Ford's Apache and mod_perl pocket books. o added a link to take23.org o added a XS resources section o added a link to the scalable list archive o remove the mailing list post address, to make it easier of Ask to filter SPAM. * troubleshooting.pod o new: exit signal Segmentation fault (11) with mysql: (Matt Sergeant) o improved the docs of fixing a broken /dev/null * debug.pod o updated gdb says there are no debugging symbols -- a simpler technique to have the binary unstripped during make install. * Minor corrections: o debug.pod (Alexander Farber) o performance.pod (Marc Lehmann, Kees Vonk) o snippets.pod (Ime Smits) o porting.pod (Michele Beltrame) o config.pod (Surat Singh Bhati, Paul Cotter ) o control.pod (Aaron Johnson, Cliff Rayman, Yann Kerhervé) o modules.pod (Daniel Bohling) o install.pod (Kevin Swope, Jamie) Revision ChangesPath 1.29 +105 -1modperl-site/guide/CHANGES Index: CHANGES === RCS file: /home/cvs/modperl-site/guide/CHANGES,v retrieving revision 1.28 retrieving revision 1.29 diff -u -r1.28 -r1.29 --- CHANGES 2001/01/11 13:48:14 1.28 +++ CHANGES 2001/04/27 16:57:09 1.29 @@ -2,7 +2,111 @@ ### mod_perl Guide CHANGES file ### ### -01.01.2001 ver 1.28 +04.26.2001 ver 1.29 + +* dbm.pod: + + o updated Flawed Locking Methods Which Must Not Be Used with notes +about lock upgrading (David Harris) + +* strategy.pod: + + o added a ref to a light and fast Boa webserver + +* scenario.pod: + + o cleared out the section on open proxying with mod_proxy (Eric Cholet) + +* multiuser.pod: + + o extended the Virtual Servers Technologies section with freevsd, +freevmware, vmware and S/390 references. + +* snippets.pod: + + o removed the cache control section -- it's covered in the HTTP +headers chapter. + + o subrequests and notes working together (Darren Chamberlain) + +* performance.pod: + + o Interpolation vs List update: wrongly used the 'concatenation' +term instead of interpolation (Mark Summerfield) + + o Interpolation, Concatenation or List was rewritten + + o new: Architecture Specific Compile Options (Tim Bunce, Perrin +Harkins, Greg Cope, Owen Williams, Vivek Khera, Steve Fink, James +W Walden) + +* modules.pod: + + o Extended the docs of Apache::SubProcess module + +* porting.pod: + + o using
RE: dbm locking info in the guide
Stas, Sounds like you agree with me that downgrading locks from exclusive to shared is not a problem with the method I described in the last e-mail. Now you have a concern with upgrading locks from shared to exclusive: David, please consider this scenario: ... At some point in time, processes A and B both read from the dbm via SH lock. 1. A completes its reading and unlocks the DBM, while still having the first 4k cached. (A still has the dbm tie()'d. 2. B wants to write, so it requests an EX lock and gets it granted. This will not happen. When B requests the EX lock it will block until all of the other shared locks have been released. Process A has to release the SH lock somehow for B to get the EX lock. Either A simply finishes and releases the lock, or A requests an upgrade, is denied, and handles this by releasing the lock. When the EX lock is granted (whether from an upgrade or not), by definition no other processes can have a SH lock and be reading the database. No other processes can have a first 4k cached because no other processes can have the file open. From the flock manpage: "A single file may not simultaneously have both shared and exclusive locks." 3. B modifies the data in the first 4k, syncs it and releases the lock. 4. A asks for SH or EX lock, gets it, but its cache is invalid. = we have a data corruption (especially in the case A does writing into the first 4k) David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/ -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 22, 2001 10:22 PM To: David Harris Cc: mod_perl list Subject: RE: dbm locking info in the guide On Thu, 22 Mar 2001, David Harris wrote: Two points about switching from exclusive mode to shared mode: (1) When downgrading from EX to SH, no other processes need to have cached data invalidated because no one else can have the database open. There is no cache in other processes, therefore none to be invalidated. Explanation: Lets say the method for downgrading a lock from EX to SH is like this: write data, sync(), flock(FLOCK_SH), read data. Until the flock(FLOCK_SH) nobody else can have the database open because of the exclusive lock. Therefore, there will not be any other processes with the database open and the first 4k cached in memory when the sync() happens. David, please consider this scenario: ... At some point in time, processes A and B both read from the dbm via SH lock. 1. A completes its reading and unlocks the DBM, while still having the first 4k cached. (A still has the dbm tie()'d. 2. B wants to write, so it requests an EX lock and gets it granted. 3. B modifies the data in the first 4k, syncs it and releases the lock. 4. A asks for SH or EX lock, gets it, but its cache is invalid. = we have a data corruption (especially in the case A does writing into the first 4k) (2) When downgrading from EX to SH, our processes does not need to invalidate cached data because its cached data is correct at the sync() and the data on disk will not be changed until the database is closed. Explanation: Again we downgrade form EX to SH by doing this: write data, sync(), flock(FLOCK_SH), read data. Our cache remains valid the entire time here. With the sync(), data in our cache is written to disk, so at that point we are good. Then after the flock(FLOCK_SH) we are still good because the shared lock prevents anyone else from writing to the database and changing the data on disk. There is no need to do a re-tie(). That's correct. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: dbm locking info in the guide
On Fri, 23 Mar 2001, David Harris wrote: Stas, Sounds like you agree with me that downgrading locks from exclusive to shared is not a problem with the method I described in the last e-mail. That's correct. Now you have a concern with upgrading locks from shared to exclusive: David, please consider this scenario: ... At some point in time, processes A and B both read from the dbm via SH lock. 1. A completes its reading and unlocks the DBM, while still having the first 4k cached. (A still has the dbm tie()'d. 2. B wants to write, so it requests an EX lock and gets it granted. This will not happen. When B requests the EX lock it will block until all of the other shared locks have been released. Process A has to release the SH lock somehow for B to get the EX lock. Either A simply finishes and releases the lock, or A requests an upgrade, is denied, and handles this by releasing the lock. That's if you code it that way. Nothing prevents you from unlocking A, and then asking for some lock later. You always want to make the critical section as short as possible. So if you need to access the dbm file twice through the request. You may go through this scenario: A: flock SH B: flock SH A: flock UN B: flock EX B: flock SH A: flock SH 'A' still have the data cached and possibly invalid. Your proposed system is clean only in this case: You can never explicitly unlock dbm and then relock it without calling untie(). You can safely upgrade the lock from SH to EX and downgrade from EX to SH though, without using UN (sort of semi-atomically). When the EX lock is granted (whether from an upgrade or not), by definition no other processes can have a SH lock and be reading the database. No other processes can have a first 4k cached because no other processes can have the file open. They can, if there weren't untie()d per my above explanation. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: dbm locking info in the guide
Perhaps we have a misunderstanding here. I would NEVER flock(UN) without having just previously untie()d the database. And I would ALWAYS acquire a lock immediately before tie()ing the database. That's the point. We have to write down all the assumptions or people will do the wrong thing. I'll try to summarize our discussion later. Thanks David! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: dbm locking info in the guide
On Wed, 21 Mar 2001, Perrin Harkins wrote: Ok, what about calling sync before accesing the database? (read and write) Will it force the process to sync its data with the disk, or will it cause the corruption of the file on the disk, as the process might have a stale data? Well, that's what we don't know. As David Harris pointed out, if it does do the right thing and re-read from disk, it's probably not much better than re-opening the database. I suppose it would avoid some Perl object creation though, so it would be at least a little faster. As the person who has discovered this bad flaw in DB_File docs and made sure that the right thing will be done, may be David will have a time to go further and check up on this issue. I would definitely do it myself, but there so many things I've to do, I just cannot do it now :( Or anybody else who wants to contribute to the community by a little effort? Just grab the tgz which represents the problem, from the url posted a few days ago by David and see if you can tackle this issue of the correctness of using sync and the actual benchmarking to check whether it's faster to do tie/untie or using sync and locking... Thanks a bunch! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: dbm locking info in the guide
Stas Bekman [mailto:[EMAIL PROTECTED]] wrote: As the person who has discovered this bad flaw in DB_File docs and made sure that the right thing will be done, may be David will have a time to go further and check up on this issue. I would definitely do it myself, but there so many things I've to do, I just cannot do it now :( Or anybody else who wants to contribute to the community by a little effort? Just grab the tgz which represents the problem, from the url posted a few days ago by David and see if you can tackle this issue of the correctness of using sync and the actual benchmarking to check whether it's faster to do tie/untie or using sync and locking... Thanks a bunch! I have done some investigation of the sync method in DB_File and this is what I have determined: the sync method only writes cached information out to disk. Information already cached in the process is not invalidated causing a re-read from the disk. My example program and the annotated strace can be found here for anyone that wants to see the details: http://www.davideous.com/misc/dblockflaw-1.2-checksync/synctest.pl http://www.davideous.com/misc/dblockflaw-1.2-checksync/synctest.strace01 Here is what I think this means for locking: If you want to downgrade a lock from exclusive to shared, sync the database and change the lock status. This will allow other readers access to a fully-written database. No one else will be allowed to write the database (requiring your process to have invalidated any cached data) until you have released the shared lock. No problem there. If you want to upgrade a lock from shared to exclusive, simply request this upgrade from the locking subsystem and write to the database once an exclusive lock has been acquired. Since the database has been in a shared lock since it was opened no one has written to it. Therefore, no invalidation of cached data is required since the database on disk has not changed. Beware when upgrading shared locks to exclusive locks that: (a) you don't get a deadlock with two shared locks trying to upgrade at the same time, and (b) if your locking layer resolves this deadlock by denying one of the upgrade requests, make sure your program handles that appropriately. I imagine one would handle a lock upgrade failure by closing the database and then requesting an exclusive lock. Perhaps one would want to rollback changes made to the database or otherwise prepare for this transition. I'd rather just grab an exclusive lock at the beginning if I know there's a chance of needing to write the database later on. Or just close and re-open the database instead of trying the upgrade at all. Everyone may have their own particular application that needs something special. However, I'd rather just use a RDMS if I'm running into this level of locking details. Then again, none of that is related to sync as it is not required for a lock upgrade. :-) OK, summary: (1) Seems to me that sync should only be used for downgrading exclusive locks to shared, and that sync is well suited for this task. (2) You can upgrade locks from shared to exclusive without sync, but you might want to avoid needing to upgrade locks because of deadlock problems. Hope this helps. (Thanks for the break from the Windows2k nightmare. Why does Oracle Enterprise Manager only run on w2k?! Well, back to work :-) David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: dbm locking info in the guide
On Thu, 22 Mar 2001, David Harris wrote: Thanks, David! I have done some investigation of the sync method in DB_File and this is what I have determined: the sync method only writes cached information out to disk. Information already cached in the process is not invalidated causing a re-read from the disk. My example program and the annotated strace can be found here for anyone that wants to see the details: http://www.davideous.com/misc/dblockflaw-1.2-checksync/synctest.pl http://www.davideous.com/misc/dblockflaw-1.2-checksync/synctest.strace01 Here is what I think this means for locking: If you want to downgrade a lock from exclusive to shared, sync the database and change the lock status. This will allow other readers access to a fully-written database. No one else will be allowed to write the database (requiring your process to have invalidated any cached data) until you have released the shared lock. No problem there. Are you sure? Doesn't it contradict with the fact that other readers have already cached the first 4k of data? And you have modified the database and possibly the first 4k during the write, so if this is the case, now readers have the wrong 4k in their cache. Or do you mean that when a process that switches from EX to SH, doesn't need to re-tie(), since it has *its* cache valid. Other process do need to re-tie when acquiring any kind of lock, if they don't have none yet. The rest seems to be correct. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: dbm locking info in the guide
Stas Bekman [mailto:[EMAIL PROTECTED]] wrote: On Thu, 22 Mar 2001, David Harris wrote: If you want to downgrade a lock from exclusive to shared, sync the database and change the lock status. This will allow other readers access to a fully-written database. No one else will be allowed to write the database (requiring your process to have invalidated any cached data) until you have released the shared lock. No problem there. Are you sure? Doesn't it contradict with the fact that other readers have already cached the first 4k of data? And you have modified the database and possibly the first 4k during the write, so if this is the case, now readers have the wrong 4k in their cache. Or do you mean that when a process that switches from EX to SH, doesn't need to re-tie(), since it has *its* cache valid. Other process do need to re-tie when acquiring any kind of lock, if they don't have none yet. Two points about switching from exclusive mode to shared mode: (1) When downgrading from EX to SH, no other processes need to have cached data invalidated because no one else can have the database open. There is no cache in other processes, therefore none to be invalidated. Explanation: Lets say the method for downgrading a lock from EX to SH is like this: write data, sync(), flock(FLOCK_SH), read data. Until the flock(FLOCK_SH) nobody else can have the database open because of the exclusive lock. Therefore, there will not be any other processes with the database open and the first 4k cached in memory when the sync() happens. (2) When downgrading from EX to SH, our processes does not need to invalidate cached data because its cached data is correct at the sync() and the data on disk will not be changed until the database is closed. Explanation: Again we downgrade form EX to SH by doing this: write data, sync(), flock(FLOCK_SH), read data. Our cache remains valid the entire time here. With the sync(), data in our cache is written to disk, so at that point we are good. Then after the flock(FLOCK_SH) we are still good because the shared lock prevents anyone else from writing to the database and changing the data on disk. There is no need to do a re-tie(). David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
RE: dbm locking info in the guide
On Thu, 22 Mar 2001, David Harris wrote: Two points about switching from exclusive mode to shared mode: (1) When downgrading from EX to SH, no other processes need to have cached data invalidated because no one else can have the database open. There is no cache in other processes, therefore none to be invalidated. Explanation: Lets say the method for downgrading a lock from EX to SH is like this: write data, sync(), flock(FLOCK_SH), read data. Until the flock(FLOCK_SH) nobody else can have the database open because of the exclusive lock. Therefore, there will not be any other processes with the database open and the first 4k cached in memory when the sync() happens. David, please consider this scenario: ... At some point in time, processes A and B both read from the dbm via SH lock. 1. A completes its reading and unlocks the DBM, while still having the first 4k cached. (A still has the dbm tie()'d. 2. B wants to write, so it requests an EX lock and gets it granted. 3. B modifies the data in the first 4k, syncs it and releases the lock. 4. A asks for SH or EX lock, gets it, but its cache is invalid. = we have a data corruption (especially in the case A does writing into the first 4k) (2) When downgrading from EX to SH, our processes does not need to invalidate cached data because its cached data is correct at the sync() and the data on disk will not be changed until the database is closed. Explanation: Again we downgrade form EX to SH by doing this: write data, sync(), flock(FLOCK_SH), read data. Our cache remains valid the entire time here. With the sync(), data in our cache is written to disk, so at that point we are good. Then after the flock(FLOCK_SH) we are still good because the shared lock prevents anyone else from writing to the database and changing the data on disk. There is no need to do a re-tie(). That's correct. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: dbm locking info in the guide
On Tue, 20 Mar 2001, Perrin Harkins wrote: Stas Bekman wrote: So basically what you are saying is that sync() is broken and shouldn't be used at all. Something fishy is going on. The purpose of sync() is to flush the modifications to the disk. Saving changes to disk isn't the problem. The issue is that some of the database gets cached in memory when you open the database (even if you don't actually read anything from it), so changes made in other processes will not be seen. To get around this, you would have to somehow reload the cached data from disk just after getting a write lock but before making any changes. Unless you are talking about a process that wants to read after some other process had changed the database, and there is a hazard that the former process has the data cached and will not know that dbm has been modified. Exactly. Keeping the database open is fine as long as you have a read-only app. For read/write, you have to tie/untie every time. Or use BerkeleyDB. Ok, what about calling sync before accesing the database? (read and write) Will it force the process to sync its data with the disk, or will it cause the corruption of the file on the disk, as the process might have a stale data? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: dbm locking info in the guide
Ok, what about calling sync before accesing the database? (read and write) Will it force the process to sync its data with the disk, or will it cause the corruption of the file on the disk, as the process might have a stale data? Well, that's what we don't know. As David Harris pointed out, if it does do the right thing and re-read from disk, it's probably not much better than re-opening the database. I suppose it would avoid some Perl object creation though, so it would be at least a little faster. - Perrin
Re: dbm locking info in the guide
On Tue, 20 Mar 2001, Stas Bekman wrote: Is anyone aware of a safe to way to do multi-process read/write access through a dbm module other than BerkeleyDB.pm without tie-ing and untie-ing every time? I thought that was the only safe thing to do because of buffering issues, but this seems to be implying that careful use of sync calls or something similar would do the trick. Maybe this is just left over from before the problem with the old technique described in the DB_File docs was discovered? Any comments? Well, I wrote this based on my experience. I've used the code that does locking coupled with sync() and it worked fine. You mean with DB_File? There's a big warning in the current version saying not to do that, because there is some initial buffering that happens when opening a database. - Perrin
Re: dbm locking info in the guide
Perrin Harkins wrote: Is anyone aware of a safe to way to do multi-process read/write access through a dbm module other than BerkeleyDB.pm without tie-ing and untie-ing every time? I thought that was the only safe thing to do because of buffering issues, but this seems to be implying that careful use of sync calls or something similar would do the trick. Maybe this is just left over from before the problem with the old technique described in the DB_File docs was discovered? Any comments? I don't know how to do it safely, which is why I do the tie/untie in MLDBM::Sync in a locked critical section. I know the tie/untie MLDBM::Sync strategy with DB_File is slow, but what size data are you caching? It may be that you can use MLDBM::Sync with SDBM_File, with records 100 bytes would be good, or MLDBM::Sync with MLDBM::Sync::SDBM_File which faster through around 5000-1 byte records with Compress::Zlib installed. Generally, the tie/untie with a SDBM_File is pretty fast. Otherwise, DeWitt Clinton's Cache::Cache might also do it for you, as the file based cache is probably faster than DB_File with tie/untie per access for large records. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: dbm locking info in the guide
On Tue, 20 Mar 2001, Joshua Chamas wrote: I know the tie/untie MLDBM::Sync strategy with DB_File is slow, but what size data are you caching? I'm not. Well, actually I am, but I use BerkeleyDB which handles its own locking. I just noticed this in the Guide and figured that either it was out of date or I missed something interesting. It may be that you can use MLDBM::Sync with SDBM_File, with records 100 bytes would be good, or MLDBM::Sync with MLDBM::Sync::SDBM_File which faster through around 5000-1 byte records with Compress::Zlib installed. Generally, the tie/untie with a SDBM_File is pretty fast. I'll update the Guide to mention your module in the dbm section. - Perrin
Re: dbm locking info in the guide
On Tue, 20 Mar 2001, Perrin Harkins wrote: On Tue, 20 Mar 2001, Stas Bekman wrote: Is anyone aware of a safe to way to do multi-process read/write access through a dbm module other than BerkeleyDB.pm without tie-ing and untie-ing every time? I thought that was the only safe thing to do because of buffering issues, but this seems to be implying that careful use of sync calls or something similar would do the trick. Maybe this is just left over from before the problem with the old technique described in the DB_File docs was discovered? Any comments? Well, I wrote this based on my experience. I've used the code that does locking coupled with sync() and it worked fine. You mean with DB_File? There's a big warning in the current version saying not to do that, because there is some initial buffering that happens when opening a database. The warning says not to lock on dbm fd but an external file! That's where the problem happens. http://perl.apache.org/guide/dbm.html#Flawed_Locking_Methods_Which_Mus If you lock before you tie, and flush before you untie (or change the lock type), it should be safe. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: dbm locking info in the guide
On Wed, 21 Mar 2001, Stas Bekman wrote: You mean with DB_File? There's a big warning in the current version saying not to do that, because there is some initial buffering that happens when opening a database. The warning says not to lock on dbm fd but an external file! I think you'll still have problems with this technique, unless you tie/untie every time. I'm looking at the perldoc for DB_File version 1.76, at the section titled "Locking: the trouble with fd". At the very least, you'd have to call sync after acquiring a write lock but before writing anything. - Perrin
RE: dbm locking info in the guide
Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: I think you'll still have problems with this technique, unless you tie/untie every time. I'm looking at the perldoc for DB_File version 1.76, at the section titled "Locking: the trouble with fd". At the very least, you'd have to call sync after acquiring a write lock but before writing anything. Here is more information from the original discovery of the bug. This contains the test cases that actually show the database corruption. Also some documentation on the details such as systraces that show reading happens before the flock system call. http://www.davideous.com/misc/dblockflaw-1.2.tar.gz http://www.davideous.com/misc/dblockflaw-1.2/ Sync may or may not work, depending on how the low level buffering is implemented. If it re-reads all information from disk I don't think you have any advantage over simply closing the DB_File and opening it again. It's also worthwhile to use an external lock file because that properly locks for database creation. David Harris President, DRH Internet Inc. [EMAIL PROTECTED] http://www.drh.net/
Re: dbm locking info in the guide
On Tue, 20 Mar 2001, Perrin Harkins wrote: On Wed, 21 Mar 2001, Stas Bekman wrote: You mean with DB_File? There's a big warning in the current version saying not to do that, because there is some initial buffering that happens when opening a database. The warning says not to lock on dbm fd but an external file! I think you'll still have problems with this technique, unless you tie/untie every time. I'm looking at the perldoc for DB_File version 1.76, at the section titled "Locking: the trouble with fd". At the very least, you'd have to call sync after acquiring a write lock but before writing anything. Of course, you always call sync. The sync was always there, even with the flawed locking scheme. The DB_File doc was updated as a follow up of the research done by David Harris. This should work: flock SH tie() read... flock EX = start critical section write... sync() flock SH = end critical section read... untie() flock UN notice that the locking is done on the *external* file (or fd). The only problem in this approach is a possible writing starvation as explained: http://perl.apache.org/guide/dbm.html#Locking_dbm_Handlers_and_Write_L _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
RE: dbm locking info in the guide
On Tue, 20 Mar 2001, David Harris wrote: Perrin Harkins [mailto:[EMAIL PROTECTED]] wrote: I think you'll still have problems with this technique, unless you tie/untie every time. I'm looking at the perldoc for DB_File version 1.76, at the section titled "Locking: the trouble with fd". At the very least, you'd have to call sync after acquiring a write lock but before writing anything. Here is more information from the original discovery of the bug. This contains the test cases that actually show the database corruption. Also some documentation on the details such as systraces that show reading happens before the flock system call. http://www.davideous.com/misc/dblockflaw-1.2.tar.gz http://www.davideous.com/misc/dblockflaw-1.2/ Sync may or may not work, depending on how the low level buffering is implemented. So basically what you are saying is that sync() is broken and shouldn't be used at all. Something fishy is going on. The purpose of sync() is to flush the modifications to the disk. If it re-reads all information from disk I don't think you have any advantage over simply closing the DB_File and opening it again. Why should it re-read the file, when it's suppose to *write* it down to the disk. That's the benefit of using dbm, is that only some blocks of the file are read into a memory. Unless you are talking about a process that wants to read after some other process had changed the database, and there is a hazard that the former process has the data cached and will not know that dbm has been modified. It's also worthwhile to use an external lock file because that properly locks for database creation. That's for sure. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: dbm locking info in the guide
Stas Bekman wrote: So basically what you are saying is that sync() is broken and shouldn't be used at all. Something fishy is going on. The purpose of sync() is to flush the modifications to the disk. Saving changes to disk isn't the problem. The issue is that some of the database gets cached in memory when you open the database (even if you don't actually read anything from it), so changes made in other processes will not be seen. To get around this, you would have to somehow reload the cached data from disk just after getting a write lock but before making any changes. Unless you are talking about a process that wants to read after some other process had changed the database, and there is a hazard that the former process has the data cached and will not know that dbm has been modified. Exactly. Keeping the database open is fine as long as you have a read-only app. For read/write, you have to tie/untie every time. Or use BerkeleyDB. - Perrin
dbm locking info in the guide
While working on adding info on Berkeley DB to the Guide, I came across this statement: "If you need to access a dbm file in your mod_perl code in the read only mode the operation would be much faster if you keep the dbm file open (tied) all the time and therefore ready to be used. This will work with dynamic (read/write) databases accesses as well, but you need to use locking and data flushing to avoid data corruption." Is anyone aware of a safe to way to do multi-process read/write access through a dbm module other than BerkeleyDB.pm without tie-ing and untie-ing every time? I thought that was the only safe thing to do because of buffering issues, but this seems to be implying that careful use of sync calls or something similar would do the trick. Maybe this is just left over from before the problem with the old technique described in the DB_File docs was discovered? Any comments? - Perrin
Re: dbm locking info in the guide
On Mon, 19 Mar 2001, Perrin Harkins wrote: While working on adding info on Berkeley DB to the Guide, I came across this statement: "If you need to access a dbm file in your mod_perl code in the read only mode the operation would be much faster if you keep the dbm file open (tied) all the time and therefore ready to be used. This will work with dynamic (read/write) databases accesses as well, but you need to use locking and data flushing to avoid data corruption." Is anyone aware of a safe to way to do multi-process read/write access through a dbm module other than BerkeleyDB.pm without tie-ing and untie-ing every time? I thought that was the only safe thing to do because of buffering issues, but this seems to be implying that careful use of sync calls or something similar would do the trick. Maybe this is just left over from before the problem with the old technique described in the DB_File docs was discovered? Any comments? Well, I wrote this based on my experience. I've used the code that does locking coupled with sync() and it worked fine. I know that the guide doesn't cover the details, this is one of the things that needs to be done. I also suppose that this issue should be properly benchmarked, but I think that it's safe to assume that skipping tie/untie improves the speed. Certainly the note "would be much faster,..." is correct if the interaction with a dbm file is very light, which makes the overhead of tie of a significance. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: mod_perl guide corrections: in uris
At 02:54 12/02/2001 +0100, Marc Lehmann wrote: Stas told me to forward my mail to the list, since there was a large discussion about it. Since I now see that this seems to have been a kind of dispute and not an ommision I'll provide references to the standards below. - Forwarded message from Marc Lehmann [EMAIL PROTECTED] - in http://perl.apache.org/guide/browserbugs.html I read: Preventing QUERY_STRING from getting corrupted because of entity key names: http://my.site.com/foo.pl?foo=barreg=foobar, then some browsers will interpret reg as an SGML entity This claims this is a browser bug, which it isn't. Browsers are perfectly fine to interpret the reg as an entity when you embed this in the html source unquoted. I don't think so. The browser would be right to treat reg; as an entity, not reg. If it had proper heuristics for dealing with poor HTML, it'd detect that there is no ; in sight for the next n chars, or that reg= isn't the start of an entity it knows about, and it would treat the as a literal. However, I agree that people should try their best to write proper html. If the above url appeared in a link it should be encoded as http://my.site.com/foo.pl?foo=baramp;reg=foobar. I find that a lot of developers don't care the least about the html they output because they somehow despise it. Think twice: take out the html, what's left of your site ? XHTML clearly forbids such wrong constructs (won't even parse if you get it wrong) and that's cool. It's like use strict for HTML. -- robin b. In which level of metalanguage are you now speaking?
Re: mod_perl guide corrections: in uris
On Mon, Feb 12, 2001 at 03:13:55AM +0100, Robin Berjon [EMAIL PROTECTED] wrote: I don't think so. The browser would be right to treat reg; as an entity, not reg. But why? It's not HTML in the first place, so expecting from clients to interpret it in one way or another is not sensible. If it had proper heuristics for dealing with poor HTML, it'd detect that there is no ; in sight for the next n chars, or that reg= isn't While one might rgue that clients should apply heuristics, given the large amount of borken html out there, one has to remember that the source for this broken html WAS sloppy html parsers with heuristics. If netscape and mosaic had flagged syntax errors nobody would expect browsers to implement heuristics today :( However, I agree that people should try their best to write proper html. If Especially since you can only choose between theoretically incorerct and in practise sometimes not working AND theoretically correct and working alway sin practise I think the choise should be clear ;) somehow despise it. Think twice: take out the html, what's left of your site ? XHTML clearly forbids such wrong constructs (won't even parse if you get it wrong) and that's cool. It's like use strict for HTML. Which is exactly my point ;) Implying this is a browser bug will only make more people insist on outputting "correct" code. After all, the clients must be fixed ;- -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: mod_perl guide corrections: in uris
At 03:26 12/02/2001 +0100, Marc Lehmann wrote: On Mon, Feb 12, 2001 at 03:13:55AM +0100, Robin Berjon [EMAIL PROTECTED] wrote: I don't think so. The browser would be right to treat reg; as an entity, not reg. But why? It's not HTML in the first place, so expecting from clients to interpret it in one way or another is not sensible. Either a client has heuristics to deal with broken stuff or it hasn't. If it does, I'd expect it to go the whole way on a simplistic case as the one above. If it had proper heuristics for dealing with poor HTML, it'd detect that there is no ; in sight for the next n chars, or that reg= isn't While one might rgue that clients should apply heuristics, given the large amount of borken html out there, one has to remember that the source for this broken html WAS sloppy html parsers with heuristics. If netscape and mosaic had flagged syntax errors nobody would expect browsers to implement heuristics today :( It's a chicken and egg problem. See how Netscape 6 / Mozilla is being bashed by designers out there. They all think it's a broken browser because it won't take their broken HTML. It tries hard (if you don't put a doctype, or put an old one) to emulate Netscape 4 brokenness, but it can't go all the way. As a result all those people are not using it, and are telling everyone not to use it. When you think that most of the time those people are considered "experts" in HTML/the web by others around them you can tell that a browser won't get accepted if those braindead pseudo-experts aren't happy with it. The only way out is careful education, and that's going to take time. However, I agree that people should try their best to write proper html. If Especially since you can only choose between theoretically incorerct and in practise sometimes not working AND theoretically correct and working alway sin practise I think the choise should be clear ;) True. It's really easy to produce html that does whatever you want and is correct. And is accessible. The main argument I use when convincing people (and I have to do that a lot) is forward compatibility. If it's correct now it'll always be. Today's heuristics may disappear with the next browser version. somehow despise it. Think twice: take out the html, what's left of your site ? XHTML clearly forbids such wrong constructs (won't even parse if you get it wrong) and that's cool. It's like use strict for HTML. Which is exactly my point ;) Implying this is a browser bug will only make more people insist on outputting "correct" code. After all, the clients must be fixed ;- We are in agreement :-) That isn't a browser bug and should be removed from the list. -- robin b. "Windows may be pretty. And easy. But it has no depth or soul. It's like the one-night stand of operating systems. You feel cheap after using it." -- Steph, in User Friendly
Re: ANNOUNCE: mod_perl guide ver. 1.28
On Thu, Jan 11, 2001 at 03:09:43PM +0100, Stas Bekman wrote: * dbm.pod: o reviewed/rewritten/corrected Any volunteers to extend this, or at least suggest additions, in relation to using Berkeley DB v3 in 'shared memory' configuration? Tim.
Re: ANNOUNCE: mod_perl guide ver. 1.28
On Thu, 11 Jan 2001, Stas Bekman wrote: Une nouvelle version du guide de mod_perl est en ligne et habituels aux endroits (My Paris farewell release :) Online: HTML: http://perl.apache.org/guide/ PDF : http://perl.apache.org/guide/mod_perl_guide.pdf.gz CPAN: file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.28.tar.gz size: 464878 bytes md5: 54e70986b2369762fc37b3c7838dbd85 FWIW, Take23 copy updated to reflect this new release. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\
RE: [ANNOUNCE] new site: scaling mod_perl will be movin to the Guide
I've gotten in touch with Stas, and the 'scaling mod_perl' site will eventually be folded into the Guide. woohoo! I'm going to spend several weeks fleshing it out and cleaning it up before it goes in, though. -Ed -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Friday, December 08, 2000 12:36 PM To: Ed Park; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [ANNOUNCE] new site: scaling mod_perl (+tool: mod_perl + DBD::Oracle) The enterprise mod_perl architectures idea that I posted earlier has evolved into a slightly modified idea: a 'scaling mod_perl' site: http://www.lifespree.com/modperl. The point of this site will be to talk about synthesize techniques for scaling, monitoring, and profiling large, complicated mod_perl architectures. No offense, but the content you have here looks really well suited to be part of the Guide. It would fit nicely into the performance section. Making it a separate site kind of fragments the documentation. So far, I've written up a basic scaling framework, and I've posted a particular development profiling tool that we wrote to capture, time, and explain all SQL select queries that occur on a particular page of a mod_perl + DBD::Oracle application: -http://www.lifespree.com/modperl/explain_dbitracelog.pl -http://www.lifespree.com/modperl/DBD-Oracle-1.06-perfhack.tar.gz Take a look at DBIx::Profile as well. 1. Performance benchmarking code. In particular, I'm looking for tools that can read in an apache log, play it back realtime (by looking at the time between requests in the apache log), and simulate slow simultaneous connections. I've started writing my own, but it would be cool if something else out there existed. The mod_backhand project was developing a tool like this called Daquiri. If folks could just send me pointers to various caching modules and code, I'll test them in a uniform environment and let folks know what I come up with. There are a bunch of discussions about this in the archives, including one this week. Joshua Chamas did some benchmarking on a dbm-based approach recently. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RFC: mod_perl Guide 2.0
Since we have already started working on mod_perl-2.0, I wanted to get in early and provide the base for the one and only source of mod_perl documentation. These are the things that I see important: 1. *All* pods located under one roof. API, Installation, Configuration, Tips, Trick and more. 2. Automatic retrieval of pods sections from .pm files and integration in the documentation tree. 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are already working in the guide, other formats to come). 4. Distribution within mod_perl or outside of it? (The main point of having documentation separated as it may be updated more often than software releases.) so this is arguable. 5. Commit rights. Should be available for all mod_perl committers, one or more persons will be responsible for keeping the healthy layout of the documentation, review documentation commits. Pretty much making it a real community project and not Stas Bekman's project. 6. Mailing list (or reuse of cvs list) for corrections/contributions 7. The relevant parts from the current guide is to be merged into the new guide and eventually freezed as mod_perl-2.0 will become the main product, and mod_perl-1.x will be not supported anymore (I suppose a few years from now). Comments are welcome. Once Doug gets back, given his approval we will start to layout the documentation infrastructure in the cvs tree. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl Guide 2.0
On Tue, 5 Dec 2000, Stas Bekman wrote: Since we have already started working on mod_perl-2.0, I wanted to get in early and provide the base for the one and only source of mod_perl documentation. These are the things that I see important: 1. *All* pods located under one roof. API, Installation, Configuration, Tips, Trick and more. Is the guide the best place for tips and tricks? Its certainly the best place for hard-core installation configuration and other stuff, but often tips and tricks focus on one particular technology. Are we missing out on having a place to store smaller tips and tricks (you know where I'm thinking of keeping them...) ? 2. Automatic retrieval of pods sections from .pm files and integration in the documentation tree. Is that really necessary? I assume you mean having the Apache.pm docs as part of the guide, and the mod_perl*.pod files also? 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are already working in the guide, other formats to come). What other formats do you think people want/need? 4. Distribution within mod_perl or outside of it? (The main point of having documentation separated as it may be updated more often than software releases.) so this is arguable. Yes, keep it out of mod_perl. We all love doug but he's slower than a very slow thing on a Sunday :-) 5. Commit rights. Should be available for all mod_perl committers, one or more persons will be responsible for keeping the healthy layout of the documentation, review documentation commits. Pretty much making it a real community project and not Stas Bekman's project. /me spies the ulterior motive behind that :-) 6. Mailing list (or reuse of cvs list) for corrections/contributions Is there anything wrong with using this list for that? 7. The relevant parts from the current guide is to be merged into the new guide and eventually freezed as mod_perl-2.0 will become the main product, and mod_perl-1.x will be not supported anymore (I suppose a few years from now). We probably need to keep two separate projects, going on what is known about mod_perl 2.0 so far. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl Guide 2.0
Suddenly, Stas Bekman uttered:
Since we have already started working on mod_perl-2.0, I wanted to get in
early and provide the base for the one and only source of mod_perl
documentation. These are the things that I see important:
2. Automatic retrieval of pods sections from .pm files and integration in
the documentation tree.
That would be nice! :)
3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
already working in the guide, other formats to come).
I'd _very_much_ like a PDA-version of the guide! It might have to be
set up differently (e.g. code snippets presented with fixed a width
font should go into seperate files, and deep nesting of lists should
be avoided (max. 2 levels?)). Lots of UI improvements could probably
be made... :)
The guide as it is, isn't much readable on my iPaq, at least. :(
4. Distribution within mod_perl or outside of it? (The main point of
having documentation separated as it may be updated more often than
software releases.) so this is arguable.
Outside, and perhaps set mod_perl to require the documentation to be
installed? (which might make installation via CPAN.pm a little easier
:)
6. Mailing list (or reuse of cvs list) for corrections/contributions
Don't we have enough mailing lists? :)
- Salve
--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua Nilsen
getc DATA}$"="'};{'";@_=unpack("C*",unpack("u*",':4@,$'.# [EMAIL PROTECTED]
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "{'@_'}"; __END__ is near! :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl Guide 2.0
On Tue, 5 Dec 2000, Salve J Nilsen wrote: 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are already working in the guide, other formats to come). I'd _very_much_ like a PDA-version of the guide! It might have to be set up differently (e.g. code snippets presented with fixed a width font should go into seperate files, and deep nesting of lists should be avoided (max. 2 levels?)). Lots of UI improvements could probably be made... :) The guide as it is, isn't much readable on my iPaq, at least. :( What's the format the iPaq can read? Isn't it an XML format? -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl Guide 2.0
Suddenly, Matt Sergeant uttered:
On Tue, 5 Dec 2000, Salve J Nilsen wrote:
3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are
already working in the guide, other formats to come).
I'd _very_much_ like a PDA-version of the guide! It might have to be
set up differently (e.g. code snippets presented with fixed a width
font should go into seperate files, and deep nesting of lists should
be avoided (max. 2 levels?)). Lots of UI improvements could probably
be made... :)
The guide as it is, isn't much readable on my iPaq, at least. :(
What's the format the iPaq can read? Isn't it an XML format?
HTML. There are two ways (AFAIK) to get web pages onto the iPaq: the
first is to use the "Mobile Favourites" feature in IE (Windows
PocketPC comes with a tiny version of IE), and the other way is by
using AvantGo, which might be looked upon as an IE application for
syncronizing web pages.
So actually, the format is HTML (dunno which versions Pocket IE can
handle, though. Maybe XHTML1.0 works? :)
I'd love to find out what might work, but it'll have to wait until
this weekend :)
- Salve
--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua Nilsen
getc DATA}$"="'};{'";@_=unpack("C*",unpack("u*",':4@,$'.# [EMAIL PROTECTED]
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "{'@_'}"; __END__ is near! :)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl Guide 2.0
On Tue, 5 Dec 2000, Matt Sergeant wrote: On Tue, 5 Dec 2000, Stas Bekman wrote: Since we have already started working on mod_perl-2.0, I wanted to get in early and provide the base for the one and only source of mod_perl documentation. These are the things that I see important: 1. *All* pods located under one roof. API, Installation, Configuration, Tips, Trick and more. Is the guide the best place for tips and tricks? Its certainly the best place for hard-core installation configuration and other stuff, but often tips and tricks focus on one particular technology. Are we missing out on having a place to store smaller tips and tricks (you know where I'm thinking of keeping them...) ? You can always reproduce them at will, I'm advocating the one and only source. There is too much confusion with the way things are now. Especially for newbies. 2. Automatic retrieval of pods sections from .pm files and integration in the documentation tree. Is that really necessary? I assume you mean having the Apache.pm docs as part of the guide, and the mod_perl*.pod files also? Absolutely, the current guide has lots of things duplicated with Apache.pm docs and the mod_perl*.pod, because it tries to be complete (well the only thing it doesn't attempt to cover is API). All we need is a well-thought layout that will make the use and maintenance easy. 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are already working in the guide, other formats to come). What other formats do you think people want/need? I don't know. Just trying to keep things open. As suggested in another reply WAP formats (or the new ones replacing WAP) 5. Commit rights. Should be available for all mod_perl committers, one or more persons will be responsible for keeping the healthy layout of the documentation, review documentation commits. Pretty much making it a real community project and not Stas Bekman's project. /me spies the ulterior motive behind that :-) No motives, it's too good to be Stas Bekman :) Others should be able to join, and contribute more, without having my shade over their head. 6. Mailing list (or reuse of cvs list) for corrections/contributions Is there anything wrong with using this list for that? Yes, you don't see all the corrections that I receive in my personal email. There are quite many of them at times. It'll create unneccesary traffic for those who aren't interested in these corrections. Believe me I know what I'm saying here :) Another item that I've forgotten about, is someone who watches the list (it was me until now and it's still me) and pickes new problems and their solutions, new technological tips and tricks and other important stuff that need to end up in the documentation and not only in the list archives. Geoff is doing a great job providing the summaries, but someone is to write down the real details. 7. The relevant parts from the current guide is to be merged into the new guide and eventually freezed as mod_perl-2.0 will become the main product, and mod_perl-1.x will be not supported anymore (I suppose a few years from now). We probably need to keep two separate projects, going on what is known about mod_perl 2.0 so far. Sure, as I said the 1.x will not die in the next few years. So once mod_perl 2.0 goes live, /guide will point to the new guide and /guide-1.x will have the old guide available. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl Guide 2.0
On Tue, 5 Dec 2000, [EMAIL PROTECTED] wrote: 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are already working in the guide, other formats to come). What other formats do you think people want/need? info files would be cool. :-) See you, -- Godoy. [EMAIL PROTECTED] Departamento de Publicações Conectiva S.A. Publishing Department Conectiva Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl Guide 2.0
On 5 Dec 2000, Jorge Godoy wrote: On Tue, 5 Dec 2000, [EMAIL PROTECTED] wrote: 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are already working in the guide, other formats to come). What other formats do you think people want/need? info files would be cool. :-) is there pod or html 2info converter? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl Guide 2.0
On Tue, 5 Dec 2000, [EMAIL PROTECTED] wrote: On 5 Dec 2000, Jorge Godoy wrote: On Tue, 5 Dec 2000, [EMAIL PROTECTED] wrote: 3. Automatic generating of html/ps/pdf/other formats. (html/ps/pdf are already working in the guide, other formats to come). What other formats do you think people want/need? info files would be cool. :-) is there pod or html 2info converter? I don't know. But I've tried looking after something and I found 'rman'. It can make *roff code into: ASCII, roff, HTML, SGML (DocBook DTD -- it tries to), LaTeX LaTeX2e, RTF, Sections (just section titles), PostScript and FrameMaker. From the SGML source we can get info... but it's a conversion from an already converted code. I don't think it's going to be that good... I'll look after something to make pod or html into info and will send what I find to the list. See you, -- Godoy. [EMAIL PROTECTED] Departamento de Publicações Conectiva S.A. Publishing Department Conectiva Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: mod_perl Guide 2.0
On 05 Dec 2000, [EMAIL PROTECTED] wrote: I'll look after something to make pod or html into info and will send what I find to the list. OK, I've done homework. Module id = Pod::Texinfo DESCRIPTION converter to texinfo CPAN_USERID KJALB (Kenneth Albanowski [EMAIL PROTECTED]) CPAN_VERSION undef CPAN_FILEContact Author Kenneth Albanowski [EMAIL PROTECTED] DSLI_STATUS cdpr (pre-alpha,developer,perl,references+ties) INST_FILE(not installed) We can also use Pod::DocBook to get DocBook SGML / XML and then convert it to Texinfo files: Module id = Pod::DocBook CPAN_USERID ADESC (Alligator Descartes [EMAIL PROTECTED]) CPAN_VERSION 0.05 CPAN_FILEA/AD/ADESC/Pod-DocBook-0.05.tar.gz INST_FILE(not installed) See you, -- Godoy. [EMAIL PROTECTED] Departamento de Publicações Conectiva S.A. Publishing Department Conectiva Inc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ANNOUNCE: mod_perl guide v. 1.27
The new version of the mod_perl guide is available: Online: http://perl.apache.org/guide/ PDF version (650pp): http://perl.apache.org/guide/mod_perl_guide.pdf.gz CPAN: file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.27.tar.gz size: 457620 bytes md5: 588452f68c074d51006769f3c6f3 (please allow a few hours for the mirrors to catch up with this update) (note that this release requires the version 0.3 of Pod::HtmlPsPdf, which will be automatically installed by CPAN.pm). Changes: * intro.pod: o. updated the long due credits section * correct_headers.pod: o added a link to an info page: "Prevent the browser from Caching a page" * multiuser.pod: o added a ref to "The User-mode Linux Kernel" project (related to running of many servers on the same machine safely to the system). * performance.pod: o added the http_load utility section o added notes about latency problems with db transactions "Persistent DB Connections" (Rodger Donaldson) * download.pod: o added links to http_load and Daquiri (only link to the backhand site) utilities. * troubleshooting.pod: o foo ... at /dev/null line 0 (Honza Pazdziora) o httpd keeps on growing after each restart (Perrin Harkins) * debug.pod: o suggestion to use warn while debugging (Kenny Gatdula) o extended the section on using strace(1). o documented the fact that Apache::Status shouldn't be used on production machines because of the overhead that it creates (Doug). o extended the section: "Safe Resource Locking and Cleanup Code" with localized file globs example (Doug) * help.pod: o added cgi-list subscription info (Peter J. Schoenster) o started new sections: 'Get help with Unix OS flavors -- Unix OS related resources' and 'Get help with Performance and Scalability' * perl.pod: o new: Understanding Closures -- the Easy Way (Randal Shwartz, Perrin Harkins, Stas) o Exceptions section update: Exception::Class and Devel::StackTrace (Matt Sergeant and Dave Rolsky) * porting.pod: o new item: "Return Codes under Apache::Registry" (Eric Cholet) o "-M and other time() file tests under mod_perl" -- added a nice TransHandler to handle the time resetting (Doug) o Adding local() at "-M and other time() file tests under mod_perl" (Andreas Koenig) o Documented Apache::Reload o correction: PERL5LIB is not ignored when PerlTaintCheck is on * install.pod: o mod_proxy_add_forward setup extended with notes about --permute-module to make it easy to place mod_proxy_add_forward before mod_proxy (Larry Leszczynski) o mod_perl and php install scenario (Roy Nasser) o reviewed and extensively edited. o added an info about Aphid Apache Installer o removed the section about experimental compile option PERL_MARK_WHERE since it should go away with 2.0 (it's still mentioned in debug.pod : "Finding the Line Which Triggered the Error or Warning" (Doug) * scenario.pod: reviewed and extensively edited. * strategy.pod: reviewed and extensively edited. * Minor corrections: o install.pod: (Neil Conway, Lance Cleveland) o perl.pod: (Pavel Shmidt) o config.pod: (Michael Rendell) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: modperl-site/guide/code My-DB.pm
sbekman 00/11/26 14:02:46 Modified:guideCHANGES advocacy.html browserbugs.html config.html control.html correct_headers.html databases.html dbm.html debug.html download.html frequent.html hardware.html help.html index.html index_long.html install.html intro.html mod_perl_guide.pdf.gz modules.html multiuser.html performance.html perl.html porting.html scenario.html security.html snippets.html start.html strategy.html troubleshooting.html guide/code My-DB.pm Log: ver 1.27 * intro.pod: o. updated the long due credits section * correct_headers.pod: o added a link to an info page: "Prevent the browser from Caching a page" * multiuser.pod: o added a ref to "The User-mode Linux Kernel" project (related to running of many servers on the same machine safely to the system). * performance.pod: o added the http_load utility section o added notes about latency problems with db transactions "Persistent DB Connections" (Rodger Donaldson) * download.pod: o added links to http_load and Daquiri (only link to the backhand site) utilities. * troubleshooting.pod: o foo ... at /dev/null line 0 (Honza Pazdziora) o httpd keeps on growing after each restart (Perrin Harkins) * debug.pod: o suggestion to use warn while debugging (Kenny Gatdula) o extended the section on using strace(1). o documented the fact that Apache::Status shouldn't be used on production machines because of the overhead that it creates (Doug). o extended the section: "Safe Resource Locking and Cleanup Code" with localized file globs example (Doug) * help.pod: o added cgi-list subscription info (Peter J. Schoenster) o started new sections: 'Get help with Unix OS flavors -- Unix OS related resources' and 'Get help with Performance and Scalability' * perl.pod: o new: Understanding Closures -- the Easy Way (Randal Shwartz, Perrin Harkins, Stas) o Exceptions section update: Exception::Class and Devel::StackTrace (Matt Sergeant and Dave Rolsky) * porting.pod: o new item: "Return Codes under Apache::Registry" (Eric Cholet) o "-M and other time() file tests under mod_perl" -- added a nice TransHandler to handle the time resetting (Doug) o Adding local() at "-M and other time() file tests under mod_perl" (Andreas Koenig) o Documented Apache::Reload o correction: PERL5LIB is not ignored when PerlTaintCheck is on * install.pod: o mod_proxy_add_forward setup extended with notes about --permute-module to make it easy to place mod_proxy_add_forward before mod_proxy (Larry Leszczynski) o mod_perl and php install scenario (Roy Nasser) o reviewed and extensively edited. o added an info about Aphid Apache Installer o removed the section about experimental compile option PERL_MARK_WHERE since it should go away with 2.0 (it's still mentioned in debug.pod : "Finding the Line Which Triggered the Error or Warning" (Doug) * scenario.pod: reviewed and extensively edited. * strategy.pod: reviewed and extensively edited. * Minor corrections: o install.pod: (Neil Conway, Lance Cleveland) o perl.pod: (Pavel Shmidt) o config.pod: (Michael Rendell) Revision ChangesPath 1.27 +123 -1modperl-site/guide/CHANGES Index: CHANGES ======= RCS file: /home/cvs/modperl-site/guide/CHANGES,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- CHANGES 2000/08/21 13:18:00 1.26 +++ CHANGES 2000/11/26 22:02:18 1.27 @@ -2,6 +2,127 @@ ### mod_perl Guide CHANGES file ### ### +11.26.2000 ver 1.27 + +* intro.pod: + + o. updated the long due credits section + +* correct_headers.pod: + + o added a link to an info page: + "Prevent the browser from Caching a page" + +* multiuser.pod: + + o added a ref to "The User-mode Linux Kernel" project (related to +running of many servers on the same machine safely to the system). + +* performance.pod: + + o added the http_load utility section + + o added notes about latency problems with db transactions +"Persistent DB Connections" (Rodger Donaldson) + +* download.pod: + + o added links to http_load and Daquiri (only link to the backhand +site) utilities. + +* troubleshooting.pod: + + o foo
Re: mod_perl guide corrections
On 14 Sep 2000, Joe Schaefer wrote: 2) Apache::Request is better than your performance numbers indicate. The problem I have with your comparison with Apache::args vs Apache::Request vs CGI is that your benchmark code isn't fair. You're comparing method calls against hash-table lookups, which is apples and oranges. To get more representative numbers, try the following code instead my $args = $q-param; # hash ref you mean parms() ? the Apache::Request::parms hash ref is tied, so there are still method calls, but less than calling params(), which does extra stuff to emulate CGI::params. parms() is going to be renamed (to something less like params()) and documented as faster than using the params() wrapper, in the next release.
Re: mod_perl guide corrections
Doug MacEachern [EMAIL PROTECTED] writes:
my $args = $q-param; # hash ref
you mean parms() ? the Apache::Request::parms hash ref is tied, so
there are still method calls, but less than calling params(), which does
extra stuff to emulate CGI::params.
I just looked at line 21 from Request.pm; it looks like $q-param() returns
the same thing as $q-parms does; but surely $q-parms is even better!
parms() is going to be renamed (to something less like params()) and
documented as faster than using the params() wrapper, in the next release.
A new libapreq release? Great news! Here's YAP for libapreq - I added Dave Mitchell's
memmem in multipart_buffer.c for better portability, and made some minor changes
to apache_request.c to eliminate some unnecessary copying. I'd be glad to send
you a url to a production server, if you'd like to see it in action.
HTH, and thanks again.
--
Joe Schaefer
[EMAIL PROTECTED]
SunStar Systems, Inc.
diff -ur libapreq-0.31/c/apache_request.c libapreq/c/apache_request.c
--- libapreq-0.31/c/apache_request.c Fri Jul 2 21:00:17 1999
+++ libapreq/c/apache_request.c Sun Sep 24 22:10:18 2000
@@ -64,8 +64,20 @@
for(x=0;str[x];x++) if(str[x] == '+') str[x] = ' ';
}
-static int util_read(ApacheRequest *req, const char **rbuf)
+static int util_read(ApacheRequest *req, char **rbuf)
{
+/* could make pointer array (LoL) to capture growth
+ * p[1] - [...\0]
+ * p[2] - [\0]
+ * p[3] - [..\0]
+ *
+ * would need hi-tech flushing routine (per string)
+ * also need a hi-tech reader. is it really worth the trouble?
+ *
+ *
+ *
+ */
+
request_rec *r = req-r;
int rc = OK;
@@ -84,9 +96,9 @@
return HTTP_REQUEST_ENTITY_TOO_LARGE;
}
- *rbuf = ap_pcalloc(r-pool, length + 1);
+ *rbuf = ap_pcalloc(r-pool, length + 1); /* can we improve this? */
- ap_hard_timeout("[libapreq] util_read", r);
+ ap_hard_timeout("[libapreq] util_parse", r);
while ((len_read =
ap_get_client_block(r, buff, sizeof(buff))) 0) {
@@ -234,56 +246,56 @@
return req;
}
-static int urlword_dlm[] = {'', ';', 0};
+/* static int urlword_dlm[] = {'', ';', 0}; */
-static char *my_urlword(pool *p, const char **line)
+char *my_urlword(ApacheRequest *req, char **line)
{
-int i;
-
-for (i = 0; urlword_dlm[i]; i++) {
- int stop = urlword_dlm[i];
- char *pos = strchr(*line, stop);
- char *res;
-
- if (!pos) {
- if (!urlword_dlm[i+1]) {
- int len = strlen(*line);
- res = ap_pstrndup(p, *line, len);
- *line += len;
- return res;
- }
- continue;
- }
+char dlm[] = ";";
+long int len;
+char *word, *dlm_ptr;
- res = ap_pstrndup(p, *line, pos - *line);
+if (! *line) { return NULL; }
- while (*pos == stop) {
- ++pos;
- }
+dlm_ptr = strpbrk(*line, dlm);
- *line = pos;
+if (!dlm_ptr) {
+ word = *line;
+ *line = NULL;
+ return word;
- return res;
+} else {
+ *dlm_ptr = '\0';
+ word = *line;
+ *line = dlm_ptr + 1;
+ return word;
}
-
-return NULL;
}
-static void split_to_parms(ApacheRequest *req, const char *data)
+static void split_to_parms(ApacheRequest *req, char *data)
{
request_rec *r = req-r;
-const char *val;
-
-while (*data (val = my_urlword(r-pool, data))) {
- const char *key = ap_getword(r-pool, val, '=');
+char dlm[] = ";";
+char *word;
+char *val;
+
+do {
+ word = my_urlword(req, data); /* modifies data */
+
+ if (!(val = strchr( word, '='))) {
+ continue; /* ignores words w/o an = sign */
+ }
+
+ *val = '\0';
+ ++val;
- req_plustospace((char*)key);
- ap_unescape_url((char*)key);
req_plustospace((char*)val);
ap_unescape_url((char*)val);
+ req_plustospace((char*)word);
+ ap_unescape_url((char*)word);
+
+ ap_table_add(req-parms, word, val);
- ap_table_add(req-parms, key, val);
-}
+} while ( data ) ;
}
@@ -293,7 +305,8 @@
int rc = OK;
if (r-method_number == M_POST) {
- const char *data, *type;
+ char *data = NULL;
+ const char *type;
type = ap_table_get(r-headers_in, "Content-Type");
@@ -304,12 +317,13 @@
return rc;
}
if (data) {
- split_to_parms(req, data);
+split_to_parms(req, data);
}
+
}
if (r-args) {
- split_to_parms(req, r-args);
+ split_to_parms(req, ap_pstrdup(r-pool,r-args));
}
return OK;
@@ -439,7 +453,7 @@
}
if (r-args) {
- split_to_parms(req, r-args);
+ split_to_parms(req, ap_pstrdup(r-pool,r-args));
}
return OK;
diff -ur libapreq-0.31/c/multipart_buffer.c libapreq/c/multipart_buffer.c
--- libapreq-0.31/c/multipart_buffer.c Sat May 1 02:44:28 1999
+++ libapreq/c/multipart_buffer.c Fri Sep 22 02:14:25 2000
@@ -55,134 +55,180 @@
*
*/
+/* JS: 6/30/2000
+ * This should fix the memory allocation issues, and handle client disconnects
+ * gracefully. Comments in the code should explain what I think is going on.
+ */
+
+
#include
Re: patches to mod_proxy (was: Re: mod_perl guide corrections)
On Tue, Sep 19, 2000 at 03:24:50PM -0400, Joe Schaefer wrote: On linux, the ext2 filesystem is VERY efficient at buffering filesystem writes (see http://www.tux.org/lkml/#s9-12). If the post data is small ( I don't know what the default size is, but the FILE buffer for the tmpfile is adjustable with setvbuf) it's never written to disk. AFAIK, the only problem with this arrangement for small posts is the extra file descriptor consumed by the apache process. Yeah, I know it's fairly negligible, but I'm not sure the FILE buffer is the one that matters here. If I fwrite(), rewind() and then fread() again, AFAIK libc's stdio still translates this into real kernel write(), lseek(), read() [strace woudl be the final judge here]. From there, the kernel can be smart enough to not actually even touch the disk, but that doesn't work with e.g journaling filesystems which impose stronger sequential conditions on disk writes, or systems like BSD that do synchronous metadata updates. And in any case, you're still doing extra memory copies to and from kernel space. If it was hard to do it otherwise i'd agree with you, but it sounds so simple to keep it in a memory buffer when it's under 16k or some similar limit, that I just think it's much more "obviously right" to do it that way. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Re: patches to mod_proxy (was: Re: mod_perl guide corrections)
Roger Espel Llima [EMAIL PROTECTED] writes: On Tue, Sep 19, 2000 at 03:24:50PM -0400, Joe Schaefer wrote: On linux, the ext2 filesystem is VERY efficient at buffering filesystem writes (see http://www.tux.org/lkml/#s9-12). If the post data is small ( I don't know what the default size is, but the FILE buffer for the tmpfile is adjustable with setvbuf) it's never written to disk. AFAIK, the only problem with this arrangement for small posts is the extra file descriptor consumed by the apache process. Yeah, I know it's fairly negligible, but I'm not sure the FILE buffer is the one that matters here. If I fwrite(), rewind() and then fread() again, AFAIK libc's stdio still translates this into real kernel write(), lseek(), read() [strace woudl be the final judge here]. From there, the kernel can be smart enough to not actually even touch the disk, but that doesn't work with e.g journaling filesystems which impose stronger sequential conditions on disk writes, or systems like BSD that do synchronous metadata updates. And in any case, you're still doing extra memory copies to and from kernel space. If it was hard to do it otherwise i'd agree with you, but it sounds so simple to keep it in a memory buffer when it's under 16k or some similar limit, that I just think it's much more "obviously right" to do it that way. Sounds good- thanks for the details. How about making a lower limit (for switching from a memory buffer to tmpfile) configurable? Any thoughts on what the directive should be called? -- Joe Schaefer [EMAIL PROTECTED] SunStar Systems, Inc.
Re: mod_perl guide corrections
[EMAIL PROTECTED] writes: What if you wanted the functionality of the fase handlers before and after the loading of the file.. Could this also be accomplished by proper use of configuration statements in http.conf? Right now I do not think so, so getting the child tied up for the time of the upload I take for granted. I'm not quite sure what your driving at. Let me see if I can describe how things work now, and what I'm trying to accomplish with the patch. Setup: A = mod_proxy enabled front-end server; keepalives enabled delivers static content (images, stylesheets, etc) proxies dynamic content B = mod_perl server; responsible for dynamic content; keepalives disabled Z = browser Event: 1) Z requests a dynamic page from A. Z -GET 1.1- A -PROXY- B -PROXY- A -CLOSE- Z The current mod_proxy CLOSES the connection from A to Z, even if Z requests keepalives, and A implements them. This is bad since subsequent requests for static content (images/stylesheets,etc.) will require a new connection. The patch should prevent mod_proxy from forcibly closing the A-Z connection. 2) Z posts form data that will ultimately be handled by B. Z -POST- A -PROXY- B Currently, mod_proxy opens the connection to B as soon as it determines B is the ultimate destination. As the POST data is read from Z to A, it is passed along directly to B. This will tie up both A and B if the A-Z connection is slow and/or the post data is huge. The patch makes mod_proxy buffer the post data in a temp file by setting the (new) ProxyPostMax directive to a positive number. If the Content-Length header supplied by Z is greater than this number, mod_proxy rejects the post request. Once the post data has been uploaded from Z-A, the patched mod_proxy opens the connection to B and delivers the POST data directly from the temp file. That's what I'm trying to accomplish with the mod_proxy patch. I've done only minimal testing on http requests; https is NOT implemented at all. I'd need something like this implemented, since I use mod_perl for authenticating "POSTers". In my case the POST data must be processed by the mod_perl server. Any help/suggestions are welcome and appreciated! -- Joe Schaefer [EMAIL PROTECTED] SunStar Systems, Inc.
Re: mod_perl guide corrections
On 14 Sep 2000, Joe Schaefer wrote: Stas, http://perl.apache.org/guide/scenario.html#Buffering_Feature ... There is no buffering of data uploaded from the client browser to the proxy, thus you cannot use this technique to prevent the heavy mod_perl server from being tied up during a large POST such as a file upload. Falling back to mod_cgi seems to be the best solution for these specific scripts whose major function is receiving large amounts of upstream data. ... What if you wanted the functionality of the fase handlers before and after the loading of the file.. Could this also be accomplished by proper use of configuration statements in http.conf? Right now I do not think so, so getting the child tied up for the time of the upload I take for granted. Of course I have been mistaken several other times. Arnold
mod_perl guide corrections
Stas,
I was looking over the latest version of the performance
section, and I have a few suggestions/comments regarding
http://perl.apache.org/guide/performance.html
1) Your description of keep-alive performance is confusing.
Every browser I've seen that implements keep-alives
will open at least 2 connections per server (HTTP/1.1 mandates
a max of 2, but 1.0 browsers like netscape open 3 or more). The
browsers are usually smart enough to round-robin the requests
between connections, so there's really no sequential delay.
Furthermore, HTTP/1.1 keepalive connections can be pipelined, to
make multiple requests on each connection without waiting for each
server response. In any real-world implementation, keepalives
are a clear winner over closed connections, even if they're
only left idle for a second or two.
Since most of us put a reverse proxy between the mod_perl server
and the browser; running keepalives on the browser-proxy connection
is desirable.
I think your section on keepalives and their usefulness should include
some of the above comments. Recently I posted a patch for mod_proxy
to the mod_perl mailing list that enables keep-alives on the browser side;
I've also written a small Apache Perl module that does the same thing.
They also do store-and-forward on the request body (POST data), which
addresses an issue you raised in
http://perl.apache.org/guide/scenario.html#Buffering_Feature
...
There is no buffering of data uploaded from the client browser to the proxy,
thus you cannot use this technique to prevent the heavy mod_perl server from
being tied up during a large POST such as a file upload. Falling back to mod_cgi
seems to be the best solution for these specific scripts whose major function is
receiving large amounts of upstream data.
...
2) Apache::Request is better than your performance numbers indicate.
The problem I have with your comparison with Apache::args vs Apache::Request vs CGI
is that your benchmark code isn't fair. You're comparing method calls against
hash-table lookups, which is apples and oranges. To get more representative
numbers, try the following code instead
processing_with_apache_request.pl
-
use strict;
use Apache::Request ();
my $r = shift;
my $q = Apache::Request-new($r);
$r-send_http_header('text/plain');
my $args = $q-param; # hash ref
print join "\n", map {"$_ = ".$$args{$_} } keys %$args;
and similiarly for CGI. The numbers you get should more accurately reflect
the performance of each.
HTH
--
Joe Schaefer
[EMAIL PROTECTED]
SunStar Systems, Inc.
Re: question on code snippet in mod_perl guide
On Thu, 31 Aug 2000, Aaron Johnson wrote: I don't work on Oracle so I will speak from my experience with MySQL. MySQL servers time out after the 8 hour standard disconnect for inactivity (this can be adjusted in your my.conf file). To compensate for this we now run our own connect checks for a valid dbh handle before it goes it all the trouble to make one along with Apache::DBI In fact there is no need for a ping, I don't see why don't you just make the timeout long enough so it'd never time out. I use 48 hours: http://perl.apache.org/guide/databases.html#The_Morning_Bug We have not had any more issues with the database connects since we moved to this method. We do a ping and validate the dbh handle rather then blindly accessing the dbh handle since Apache::DBI will only validate the dbh handle on a connect. Aaron Johnson Perrin Harkins wrote: On Thu, 31 Aug 2000 [EMAIL PROTECTED] wrote: What I think is going on is that the script gets killed by Oracle for being idle and tries to ping the connection, but the ping fails. It is supposed to reconnect when the ping fails. I've had problems getting reconnects to Oracle 8 working. The "solution" we ended up with was to make processes that can't reconnect send an error page and exit. New processes are able to connect. I'm not sure what causes this problem. Since your problem is caused by your processes being idle for too long, this may go away when you move out of testing mode into a public release. You might want to tweak your MinSpareServers settings so that you won't have lots of idle processes hanging around. Rebild your mod_perl with the EVERYTHING=1 flag. That will get rid of the above error message. So I have to re-install it? Is there anything I need to do when I rebuild it? Or do I just need to reinstall mod_perl as it's done in the documentation? Just rebuild it and re-install as it shows in the docs. - Perrin _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
question on code snippet in mod_perl guide
In the section on optimizing the db and prepare statements (in the http://perl.apache.org/guide/performance.html url), the document discusses creating a subroutine called "connect" in a package called package My::DB; My question is if you have the my $dbh = My::DB-connect; statement in another package, what exactly happens to that connection between request of the script using that package? For instance, let's say that statement was contained in package foo.pm and is used in the script bar.cgi. If this script is being loaded in mod_perl, when is this connection being re-established? Let me see if I can explain the situation that I'm dealing with. In my case, let's say I have the script bar.cgi being executed. I put some warnings in that connect subroutine that tell me when it's being called. I look at the error_log in Apache to see when this connection is being called. Let's say out of 5-6 times, the function isn't called (which presumably is because the connection is either persistent or that the module being loaded in mod_perl doesn't go away??) but on the 7th or so time I see it called. The error seems inconsistent. My guess was that the connection is maintained as a process until it goes away, but I'm not 100% certain. The situation kinda sucks because the connection gets lost or is killed by a trigger in Oracle (after 60 minutes), but I have no real way of figuring out when this situation arises. So going back to my question, when is the connection getting reestablished using this code? Anyway, while I'm on the topic of disconnecting DBs, I've been getting this error in the logs: Rebuild with -DPERL_STACKED_HANDLERS to $r-push_handlers at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 93. What is this error? How can I specifically deal with it? And lastly is this issue connected with my connection not getting reconnected occasionally? Thanks (Really tired. Sorry) -- Why is College Club the largest and fastest growing college student site? Find out for yourself at http://www.collegeclub.com
Re: question on code snippet in mod_perl guide
Hmmm. How busy is the site or is still in testing phase? Testing phase. Are you saying your connection is getting dropped and then you get an error,or that you get dropped and then it has to reconnect? Here's a sample of errors that I'm getting the error_log file: [Tue Aug 29 20:15:52 2000] null: DBD::Oracle::st execute failed: ORA-01012: not logged on (DBD ERROR: OCIStmtExecute) at /u1/web/modules/(some_dir)/process.pm line 580. [Tue Aug 29 20:25:21 2000] null: DBD::Oracle::db ping failed: ORA-02396: exceeded maximum idle time, please connect again (DBD ERROR: OCIStmtExecute/Describe) at /usr/lib/perl5/site_perl/5.005/Apache/DBI.pm line 112. What I think is going on is that the script gets killed by Oracle for being idle and tries to ping the connection, but the ping fails. I took the suggestion in Apache::DBI and replaced the ping code with the subroutine in Oracle.pm but we still encountered this issue. Later on though we want the connection back but it never makes another call to the connect subroutine that is described in the performance tuning t docs. I was guessing that the .pm file that calls the connect routine is in memory someplace so it has no need to call back connect since it assumes that the connection is still present. Then at some random interval we get that error message from apache. I'm out of ideas of what's causing this. I guess I am missing the key to the question here :^) I have some suggestions that can help, but I need to know which you are dealing with first. Cool. Any help is much appreciated :) Rebild your mod_perl with the EVERYTHING=1 flag. That will get rid of the above error message. So I have to re-install it? Is there anything I need to do when I rebuild it? Or do I just need to reinstall mod_perl as it's done in the documentation? -- Why is College Club the largest and fastest growing college student site? Find out for yourself at http://www.collegeclub.com
Re: question on code snippet in mod_perl guide
On Thu, 31 Aug 2000 [EMAIL PROTECTED] wrote: What I think is going on is that the script gets killed by Oracle for being idle and tries to ping the connection, but the ping fails. It is supposed to reconnect when the ping fails. I've had problems getting reconnects to Oracle 8 working. The "solution" we ended up with was to make processes that can't reconnect send an error page and exit. New processes are able to connect. I'm not sure what causes this problem. Since your problem is caused by your processes being idle for too long, this may go away when you move out of testing mode into a public release. You might want to tweak your MinSpareServers settings so that you won't have lots of idle processes hanging around. Rebild your mod_perl with the EVERYTHING=1 flag. That will get rid of the above error message. So I have to re-install it? Is there anything I need to do when I rebuild it? Or do I just need to reinstall mod_perl as it's done in the documentation? Just rebuild it and re-install as it shows in the docs. - Perrin
Re: question on code snippet in mod_perl guide
I don't work on Oracle so I will speak from my experience with MySQL. MySQL servers time out after the 8 hour standard disconnect for inactivity (this can be adjusted in your my.conf file). To compensate for this we now run our own connect checks for a valid dbh handle before it goes it all the trouble to make one along with Apache::DBI We have not had any more issues with the database connects since we moved to this method. We do a ping and validate the dbh handle rather then blindly accessing the dbh handle since Apache::DBI will only validate the dbh handle on a connect. Aaron Johnson Perrin Harkins wrote: On Thu, 31 Aug 2000 [EMAIL PROTECTED] wrote: What I think is going on is that the script gets killed by Oracle for being idle and tries to ping the connection, but the ping fails. It is supposed to reconnect when the ping fails. I've had problems getting reconnects to Oracle 8 working. The "solution" we ended up with was to make processes that can't reconnect send an error page and exit. New processes are able to connect. I'm not sure what causes this problem. Since your problem is caused by your processes being idle for too long, this may go away when you move out of testing mode into a public release. You might want to tweak your MinSpareServers settings so that you won't have lots of idle processes hanging around. Rebild your mod_perl with the EVERYTHING=1 flag. That will get rid of the above error message. So I have to re-install it? Is there anything I need to do when I rebuild it? Or do I just need to reinstall mod_perl as it's done in the documentation? Just rebuild it and re-install as it shows in the docs. - Perrin
ANNOUNCE: mod_perl Guide ver. 1.26
A new version of the mod_perl guide has been released. CPAN: file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.26.tar.gz size: 451448 bytes md5: 37a07ec5f147f75ed9b5b2fc8359adeb Online: HTML: http://perl.apache.org/guide/ PDF : http://perl.apache.org/guide/mod_perl_guide.pdf.gz (size: 641pp) CVS : http://stason.org/guide-snapshots/ This "early" release was mainly triggered by decoupling the guide from it's build code. The build code is now generic (decoupled from the guide) and can be used for any documentation project. The new module is called Pod::HtmlPsPdf and will be announced shortly. Changes: * mod_perl guide's build process is now completely migrated into an external module, distributed in package Pod::HtmlPSPdf. * install.pod: Raven SSL installation notes updated (Doug, Geoffrey Young) * troubleshooting.pod: install_driver(Oracle) failed: Can't load '.../DBD/Oracle/Oracle.so' for module DBD::Oracle (Yann Ramin, Richard Chen) * security.pod: a code sample in "Non authenticated access for internal IPs, Authenticated for external IPs" is corrected (Will Trillich) * porting.pod: "CHECK Blocks" (Doug) * scenario.pod: "The dual server installation scenario was complete rewritten, to accomodate a better in my opinion directories layout and simpler installation process" * perl.pod: "Exception Handling for mod_perl" was improved by Matt Sergeant. * Minor corrections: o config (Ron Pero) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perlmonth.com perl.org apache.org
cvs commit: modperl-site/guide CHANGES config.html control.html correct_headers.html help.html index.html index_long.html install.html mod_perl_guide.pdf.gz performance.html perl.html porting.html scenario.html security.html snippets.html strategy.html troubleshooting.html obvious.html
sbekman 00/08/21 06:18:23 Modified:guideCHANGES config.html control.html correct_headers.html help.html index.html index_long.html install.html mod_perl_guide.pdf.gz performance.html perl.html porting.html scenario.html security.html snippets.html strategy.html troubleshooting.html Removed: guideobvious.html Log: * mod_perl guide's build process is now completely migrated into an external module, distributed in package Pod::HtmlPSPdf. * install.pod: Raven SSL installation notes updated (Doug, Geoffrey Young) * troubleshooting.pod: install_driver(Oracle) failed: Can't load '.../DBD/Oracle/Oracle.so' for module DBD::Oracle (Yann Ramin, Richard Chen) * security.pod: a code sample in "Non authenticated access for internal IPs, Authenticated for external IPs" is corrected (Will Trillich) * porting.pod: "CHECK Blocks" (Doug) * scenario.pod: "The dual server installation scenario was complete rewritten, to accomodate a better in my opinion directories layout and simpler installation process" * perl.pod: "Exception Handling for mod_perl" was improved by Matt Sergeant. * Minor corrections: o config (Ron Pero) Revision ChangesPath 1.26 +26 -0 modperl-site/guide/CHANGES Index: CHANGES === RCS file: /home/cvs/modperl-site/guide/CHANGES,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- CHANGES 2000/08/05 20:48:04 1.25 +++ CHANGES 2000/08/21 13:18:00 1.26 @@ -2,6 +2,32 @@ ### mod_perl Guide CHANGES file ### ### +08.21.2000 ver 1.26 + +* mod_perl guide's build process is now completely migrated into an + external module, distributed in package Pod::HtmlPSPdf. + +* install.pod: Raven SSL installation notes updated (Doug, Geoffrey + Young) + +* troubleshooting.pod: install_driver(Oracle) failed: Can't load + '.../DBD/Oracle/Oracle.so' for module DBD::Oracle (Yann Ramin, + Richard Chen) + +* security.pod: a code sample in "Non authenticated access for + internal IPs, Authenticated for external IPs" is corrected (Will + Trillich) + +* porting.pod: "CHECK Blocks" (Doug) + +* scenario.pod: "The dual server installation scenario was complete + rewritten, to accomodate a better in my opinion directories layout + and simpler installation process" + +* perl.pod: "Exception Handling for mod_perl" was improved by Matt. + +* Minor corrections: + o config (Ron Pero) 08.05.2000 ver 1.25 1.28 +11 -10modperl-site/guide/config.html Index: config.html ======= RCS file: /home/cvs/modperl-site/guide/config.html,v retrieving revision 1.27 retrieving revision 1.28 diff -u -r1.27 -r1.28 --- config.html 2000/08/05 20:48:04 1.27 +++ config.html 2000/08/21 13:18:00 1.28 @@ -52,7 +52,7 @@ LIA HREF="#Alias_Configurations"Alias Configurations/A UL - LIA HREF="#Running_CGI_PerlRun_and_Regist"Running CGI, PerlRun, and Registry Scripts located in the same Directory/A + LIA HREF="#Running_CGI_PerlRun_and_Regist"Running CGI, PerlRun, and Registry Scripts Located in the Same Directory/A /UL LIA HREF="#_Location_Configuration"lt;Locationgt; Configuration/A @@ -808,7 +808,7 @@ P where latter directive invokes mod_cgi. You shouldn't use the CODEScriptAlias/CODE directive unless you want the request to be processed under mod_cgi. -Therefore when you configure a mod_perl sections use +Therefore when you configure mod_perl sections use CODEAlias/CODE instead. P @@ -818,8 +818,9 @@ A HREF="././config.html#Perl_Handlers"Perl*Handlers/A for more information about handlers for the various request phases. P -When you have decided what methods to use to run your scripts and where you -will keep them, you can add the configuration CODEdirective(s)/CODE to EMhttpd.conf/EM. They will look like those below, but they will of course reflect the +When you have decided which methods to use to run your scripts and where +you will keep them, you can add the configuration CODEdirective(s)/CODE +to EMhttpd.conf/EM. They will look like those below, but they will of course reflect the locations of your scripts in your file-system and the decisions you have made about how to run the scripts: @@ -846,7 +847,7 @@ P [ BFONT SIZE=-1A HRE
ANNOUNCE: mod_perl Guide v. 1.25
The uploaded file Apache-mod_perl_guide-1.25.tar.gz has entered CPAN as file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.25.tar.gz size: 520586 bytes md5: 7b1d0c0022139936b6b6e47cb295 The online version is at http://perl.apache.org/guide/ The PDF version is at http://perl.apache.org/guide/mod_perl_guide.pdf.gz CHANGES: * License: People asked me to redistribute mod_perl Guide in other ways than just mirroring the mod_perl site. Therefore I've licensed the guide under GPL and included the required info in the CPAN package. * perl: o added "Using Non-Hardcoded Configuration Module Names" (Chris Winters) * debug: o updated: "How can I find out if a mod_perl code has a memory leak" o rewritten: Handling the 'User pressed Stop button' case Detecting Aborted Connections The Importance of Cleanup Code Critical Section Safe Resource Locking and Cleanup Code * config: o added a sub header "Running CGI, PerlRun, and Registry Scripts located in the same Directory" to make the info more prominent to find. (Ron Pero) o PerlAddVar info was added * control o "Swapping Prevention" rewritten from scratch and moved from performance chapter to control chapter (Ed Phillips, Barrie Slaymaker, Joshua Chamas) o "Preparing for Machine Reboot" -- added a section describing the chkconfig(8) use (Andreas Koenig) * porting: o the wrong suggested solution to the nested sub problem was spotted!!! (Hunter Monroe, Hailei Dai) it's fixed now. o update: "Terminating requests and processes, the exit() and child_terminate() functions" -- under perl5.6 you don't need to override exit anymore! (Doug, Eric Cholet) o s/PerlTaintMode/PerlTaintCheck/ (Gunther Birznieks) * review: o Mark Summerfield has reviewed these chapters: modules, browserbugs, security and start. * performance: o "CGI.pm vs Apache::Request" and "Apache::args vs Apache::Request::param" were merged into a single section called: "Apache::args vs Apache::Request::param vs CGI::param" o The first example showing the use of ab was corrected (Joe Schaefer) o rewritten: + Apache::Registry PerlHandler versus Custom PerlHandler + Keeping the Shared Memory Limit + Limiting the Size of the Processes + Limiting Other Resources Used by Apache Child Processes * modules: o "Apache::GTopLimit - Limit Apache httpd processes" merged into performance chapter. o Apache::PerlVINC configuration corrected (Patrick) * Minor corrections: o config (Carl Hansen, Ron Pero, Jeff Chan, Cliff Rayman, Marcel Grunauer) o control (Marcel Grunauer) o debug (Marcel Grunauer) o install (Ron Pero) o snippets (Ask Bjoern Hansen, Chris Nokleberg) o perl (Will Trillich, Cliff Rayman, Jason Rhinelander) o porting (Ged Haywood) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
RE: search engine for the Guide
Hi,
Try http://www.comptek.ru/yandex/YandexFree.html
search engine for web servers with highlighting searched words...
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 04, 2000 2:10 PM
To: Matt Sergeant
Cc: mod_perl list
Subject: Re: search engine for the Guide
On Thu, 4 May 2000, Stas Bekman wrote:
On Wed, 3 May 2000, Matt Sergeant wrote:
On Wed, 3 May 2000, Stas Bekman wrote:
Yeah, I've been thinking about it. There was one site
that has offered me
to provide a good search engine and they did, but the
problem is that they
didn't keep up with new releases, so people were
searching the outdated
version, which is quite bad -- I've removed the
reference to it, after
asking them to update their copy for a few months,
with no results.
Can't we use WWW::Search - If I recall correctly some
of the sites can be
restricted to a domain, so you could build a search
interface pretty
easily.
DESCRIPTION :
This class is the parent for all access methods supported by the
WWW::Search library. This library implements a Perl API
to web-based
search engines.
It's not the search engine -- it's a Perl API to the
search engines. We
need a search engine not the API to it. Did I miss something?
Yes. On some of the search engines (AltaVista springs to
mind) you can
search for things on particular web sites, or even links to
particular web
sites. So as long as AltaVista keeps its search contents up
to date, you
can leverage their engine. IIRC either Randall or Lincoln did a
WebTechniques article about this a few months ago.
Oh, I see.
But I want to stress these 2 points:
1) Currently each chapter in the Guide is a huge document, so
doing search
and having a hit, doesn't really help as you still have to go thru the
page to find the exact section that you want to read. So I
think we want a
search engine that's not working with the master version per
se, but with
a copy which has name anchors for each line and:
a. can bring you to exact line with match
b. have the keyword highlighted
2) Most of the search engines have problems with keywords including
non-alpha chars, like if you search for Apache::Registry you
will end up
searching for Apache and Registry since :: is ignored. Now think about
'$r-print' 'BEGIN {', '$@', etc. All these are must for the
doc with many
non-alpha characters which should be searched for.
What do you think?
__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide
http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--
RE: search engine for the Guide
On Fri, 23 Jun 2000, Vladislav Safronov wrote:
Hi,
Try http://www.comptek.ru/yandex/YandexFree.html
search engine for web servers with highlighting searched words...
Heh, it helps when you know Russian and have the font installed :)
Oh, I see the English link:
http://www.comptek.ru:8100/english/yandex/YandexFree.html
Thanks Vladislav, but I think we are already quite happy with the two new
engines provided by Randy and Vivek and the new version of the split
guide, I really like it :). BTW, Randy's engine highlightes the words.
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 04, 2000 2:10 PM
To: Matt Sergeant
Cc: mod_perl list
Subject: Re: search engine for the Guide
On Thu, 4 May 2000, Stas Bekman wrote:
On Wed, 3 May 2000, Matt Sergeant wrote:
On Wed, 3 May 2000, Stas Bekman wrote:
Yeah, I've been thinking about it. There was one site
that has offered me
to provide a good search engine and they did, but the
problem is that they
didn't keep up with new releases, so people were
searching the outdated
version, which is quite bad -- I've removed the
reference to it, after
asking them to update their copy for a few months,
with no results.
Can't we use WWW::Search - If I recall correctly some
of the sites can be
restricted to a domain, so you could build a search
interface pretty
easily.
DESCRIPTION :
This class is the parent for all access methods supported by the
WWW::Search library. This library implements a Perl API
to web-based
search engines.
It's not the search engine -- it's a Perl API to the
search engines. We
need a search engine not the API to it. Did I miss something?
Yes. On some of the search engines (AltaVista springs to
mind) you can
search for things on particular web sites, or even links to
particular web
sites. So as long as AltaVista keeps its search contents up
to date, you
can leverage their engine. IIRC either Randall or Lincoln did a
WebTechniques article about this a few months ago.
Oh, I see.
But I want to stress these 2 points:
1) Currently each chapter in the Guide is a huge document, so
doing search
and having a hit, doesn't really help as you still have to go thru the
page to find the exact section that you want to read. So I
think we want a
search engine that's not working with the master version per
se, but with
a copy which has name anchors for each line and:
a. can bring you to exact line with match
b. have the keyword highlighted
2) Most of the search engines have problems with keywords including
non-alpha chars, like if you search for Apache::Registry you
will end up
searching for Apache and Registry since :: is ignored. Now think about
'$r-print' 'BEGIN {', '$@', etc. All these are must for the
doc with many
non-alpha characters which should be searched for.
What do you think?
__
Stas Bekman | JAm_pH--Just Another mod_perl Hacker
http://stason.org/ | mod_perl Guide
http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/
http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org
--
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
RE: ANNOUNCE: mod_perl Guide 1.24
Stas, I just logged on to CPAN to download the latest version of the guide, and even though CPAN thinks version 1.24 is there (search for mod_perl_guide) the actual file is not there in your directory (this was at 11:20 BST (08/06/2000)). Kees
Re: ANNOUNCE: mod_perl Guide 1.24
Kees Vonk 7249 24549 wrote: Stas, I just logged on to CPAN to download the latest version of the guide, and even though CPAN thinks version 1.24 is there (search for mod_perl_guide) the actual file is not there in your directory (this was at 11:20 BST (08/06/2000)). What server are you getting it from? May be it's a broken mirror? I get this one with no problems Hey may be the mirror wasn't completed when you have tried it and it was in the middle? http://www.perl.com/CPAN-local/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.24.tar.gz Hey may be the mirror wasn't completed when you have tried it and it was in the middle? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: ANNOUNCE: mod_perl Guide 1.24
Stas, I was searched at search.cpan.org and then followed the link from there, as far as I know that is a link to www.perl.com. Kees
Re: ANNOUNCE: mod_perl Guide 1.24
"SB" == Stas Bekman [EMAIL PROTECTED] writes: SB mod_perl Guide Version 1.24 Jun 7, 2000 has been released. [ ... ] SB New 2 search engines and splitted version of the Guide. Vivek's version is SB almost up to date, Randy's is not. So please use Vivek's version for SB search. The search form is at http://perl.apache.org/guide/. The nextrieve-based search is now up-to-date with Guide 1.24. Let me know if there are any problems with it.
Re: ANNOUNCE: mod_perl Guide 1.24
Stas, just did another search and now (13:15 BST) it is there. Kees
ANNOUNCE: mod_perl Guide 1.24
mod_perl Guide Version 1.24 Jun 7, 2000 has been released.
The online version:
http://perl.apache.org/guide/
The PDF version: 631pages (1,810KB compressed)
http://perl.apache.org/guide/mod_perl_guide.pdf.gz
The sources at CPAN:
file: $CPAN/authors/id/S/ST/STAS/Apache-mod_perl_guide-1.24.tar.gz
size: 526902 bytes
md5: 0df696c91cf252254f2b442ff506b662
The CVS sources, the latest snapshots at:
http://www.stason.org/guide-snapshots/
The Changes:
New 2 search engines and splitted version of the Guide. Vivek's version is
almost up to date, Randy's is not. So please use Vivek's version for
search. The search form is at http://perl.apache.org/guide/.
If any of corrections/notes didn't enter this version, I promise to put
it in on the next release.
06.07.2000 ver 1.24
* perl: "catching exceptions" -- a few corrections (Matt Sergeant)
* modules: added Apache::Gzip (Ken Williams)
* guide's design
o put back the links underlining
o background-color: #ee;
o added (jump) menus to reach search/download/index from everywhere
o added the two new search engines (both working on the split
version of the guide)
* guide's build:
o The build code was completely rewritten, html2ps is now bundled
with the guide so one can create PS version, and if there is
ps2pdf the PDF version.
o It can produce the split version of the Guide.
o One can easily reuse the package to build his own docs, since the
look-n-feel has been moved into the templates from the code.
o Once I feel confident I'll probably separate the build code from
the Guide to give it its own life and make it easier to reuse by
other developers. I need testers who want to use this package
before I release it a separate module.
* performance:
o old sections rewritten/improved:
- Are My Variables Shared?
- Preloading Registry Scripts
- Calculating Real Memory Usage
- Preloading Perl Modules at Server Startup
- Preloading Registry Scripts at Server Startup
- Forking and Executing Subprocesses from mod_perl
= Spawning a Detachable Sub-Process
= Gory Details About fork()
= Executing system() in the Right Way
= Avoiding Zombie Processes
o new sections:
- Apache/mod_perl Build Options
= mod_perl Process Size as a Function of Compiled in C Modules and
mod_perl Features
- Modules Initializing at Server Startup
= Initializing DBI.pm (corrections by Tim Bunce)
= Initializing CGI.pm
* control:
o These sections were rewritten and extended:
- Server Maintenance Chores
= Handling Log Files
+ Log Rotation
+ Non-Scheduled Emergency Log Rotation
o 'cyclog' is now called multilog (from daemontools package)
o Moved from debug and rewritten "Speeding up the Apache Termination
and Restart"
o Rewritten and extended "SUID Start-up Scripts" with:
"Introduction to SUID Executables"
"Apache Startup SUID Script's Security"
"Sample Apache Startup SUID Script"
* hardware: partly rewritten and improved.
* reconstruction process: obvious.pod has been disassembled and merged
into debug.pod.
* debug: update: Apache::DumpHeaders (Ask Bjoern Hansen)
* troubleshooting: PerlFreshRestart is irrelevant for DSO (Vivek
Khera, Doug)
* review:
o Drew Taylor has reviewed these chapters: scenario and strategy
chapters.
o Mark Summerfield has reviewed these chapters: scenario, perl and
strategy chapters.
o Eric Cholet has reviewed the porting chapter.
* Minor corrections:
o download (Salve J Nilsen)
o performance (w trillich)
o perl (Scott Holdren)
o snippets+download (Ask Bjoern Hansen)
o debug (Robert Mathews)
o scenario (Tuomas Salo)
Enjoy!
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC
http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: ANNOUNCE: mod_perl Guide 1.24
This is notify you that Randy's guide search engine's content is up to date, and Vivek's version is almost up-todate, so you can use both now. Enjoy! _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Re: Warning about guide exceptions docs...
On Sun, 4 Jun 2000, Stas Bekman wrote: On Sat, 3 Jun 2000, Matt Sergeant wrote: Just a "heads up" about the exceptions section of the guide. Don't try and create more than one generic exception handler on your server. As I've just discovered it really confuses things. Create one class and one class only for handling exceptions globally. Matt, will you please send me an update? I still didn't get a chance to dig into your exceptions guide. OK - could you possibly email me the current perl.pod so that I don't have to go downloading the whole thing? Also, the die overloading needs a prototype to work like the real die(). Maybe I should put out a CPAN release: SimpleException.pm or something? Sounds good! Will you really do it? Well it would be trivial - I'll ask [EMAIL PROTECTED] -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Warning about guide exceptions docs...
On Sat, 3 Jun 2000, Matt Sergeant wrote: Just a "heads up" about the exceptions section of the guide. Don't try and create more than one generic exception handler on your server. As I've just discovered it really confuses things. Create one class and one class only for handling exceptions globally. Matt, will you please send me an update? I still didn't get a chance to dig into your exceptions guide. Maybe I should put out a CPAN release: SimpleException.pm or something? Sounds good! Will you really do it? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
Warning about guide exceptions docs...
Just a "heads up" about the exceptions section of the guide. Don't try and create more than one generic exception handler on your server. As I've just discovered it really confuses things. Create one class and one class only for handling exceptions globally. Maybe I should put out a CPAN release: SimpleException.pm or something? -- Matt/ Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Guide search engine (was Re: multiple copies of a module)
On Wed, 17 May 2000, Jeremy Howard wrote: ...the perl.apache.org search facility * Where is it? (doing a Find on the front page doesn't show it) At the bottom of all guide pages. How funny--I'd never even noticed it! I see that it's using 'Swish-E' http://sunsite.berkeley.edu/SWISH-E/. Stas--did you get that up and running? Can we tailor it for our needs? Here's an attempt at listing what I think we've decided we should aim for: - Allow restriction of search to just the guide - Allow searching of other documents through a popup selection (probably make the guide the default?) - Highlight found words - Try and index in a way that suits programmers, not English writers. e.g. include @, %, $, ::, in indexed words. Have I missed anything? (I'm ignoring the docbook issue for the moment since it's not directly related, and I guess it's really Stas' call anyhow.) So far these are the engines that we are going to deplo: 1st search: Randy Kobes: swish engine + perl filters http://theoryx5.uwinnipeg.ca/cgi-bin/guide-search 2nd search: Vivek Khera: nextrieve engine http://thingy.kcilink.com/cgi-bin/modperlguide.cgi Both more or less cover the demands from my yours and mine wishlists. I'll link to these from the Guide. You are welcome to present other search engines if you think you can get a better one. I promise to link to all of them, assuming that you will take the responsibility to keep up with updates. I'll delete all the references to search engines which will not update their indexed version as I did before with some quite good search engine that didn't keep up with updates and had half a year old version, and users were using a *very* outdated guide as a result. I would have thought the best bet would be to put it on the footer of every perl.apache.org page. A popup which allows selecting a subset of the site might default to either 'whole site' or 'mod_perl Guide', or maybe it changes it's default to whatever part of the site is currently being viewed... The outstanding issues, I believe, are: - Who looks after the perl.apache.org search facility? Are they happy to expand its functionality as described? - What tool? Potential options so far are Swish-e, htdig, or custom Perl (perhaps based on Matt's engine). Any of these could be piped through a word-hilighting filter - What's the best 1st step? i.e. How can we get a simple search going quickly, while providing the foundation for a more complete system down the track? - Who's going to do the actual work? As I've mentioned, if a machine is required, I'm happy to provide it. However, I don't have the experience in this area to lead the work--although of course I'll contribute where I can! It would be nice to get a private mailing list going to avoid filling up this list too much more. Anyone who's interesting in getting involved, email me, and I'll ensure that I add your name to the list. You don't have to be a programming guru, of course... there's always plenty of ways to get involved in these things. Well, things are just happening. Vivek and Randy already created their versions and presented them at the list, received feedbacks, made corrections and have the engines working. As I've mentioned above you are very welcome to beat their achievement and get an even better engine :) P.S. Asking "who is going to do that" is a bad idea on this list... I'm not bitching, Just telling the fact. If you want something to be done either ask for help or do it yourself. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://perl.org http://stason.org/TULARC http://singlesheaven.com http://perlmonth.com http://sourcegarden.org
