Re: books reviewing (was Re: PerlRestartHandler)
On Fri, 30 Mar 2001, Gunther Birznieks wrote: At 06:44 PM 3/29/01 +0800, Stas Bekman wrote: Indeed, I've often wished O'Reilly would provide book sources for people that have bought the treebook. Manning has something like that, you can buy the ebook cheaper than the actual book, and then if you decide to buy the treebook it's that much cheaper. I agree. Meanwhile you can always get the source by helping others to review books :) /me goes off to read a certain book which he'd promised to review but hasn't quite finished... make sure to grab the latest version of the sources though, we have done lots of small patches in the last days... I wish others who have promised to help to review the book were actually helping us :( We gotta release it asap, but the book was hardly touched by reviewers... I guess we will just release it as it is... don't be surprised if there will be some glitches in it... what can we do... You shouldn't worry so much. Considering that the mod_perl guide was an open source effort in the first place, I suspect the book will have already been quite well reviewed even if you've added a lot. I do worry about it. The guide was many time considered as having the ultimately correct information, and some of the broken stuff has been revealed years after it was placed there. People were taking things for granted, instead of getting the information scrutinuzed. Definitely the information there had been corrected many times, but it has too much information for me to feel calm that most of it correct. Our first book 7 years ago has a really stupid Y2K bug (stupid because the code says it takes Y2K into account and then goes on to not...) and oh yeah, some race condition in some of the file-based locking code...and ... we didnt use taint mode... and... files were opened without explicit and operators...and In the end though, for the audience of our book, we had gotten much more praise than flames. The important thing was that we released something to enable people to start coding web apps that were very highly documented relative to other free web apps written in Perl. And regardless of the quality -- still *at the time*, higher quality than many other free web apps. So in the end, I think we would have done a disservice by vetting the book more technically and waiting another year than the way we did it -- just release it. You see, for us, there is no such a thing as "good enough". We are open source people and compared to commercial bodies who are willing to releases unfinished products because there are just good enough and better than their competitors, we don't accept that. We want to code and documentation be perfect, and we aren't ready to release the final version of it claiming it to be a final version before it's perfect. That's why the mod_perl guide and other online documentation projects are great. Because it has never been claimed to be perfect, it's going through the constant change. And one should never consider it to be ultimately correct. It's in the constant beta version. Things are very different with deadtree versions of the documentation. It's parallel to a product release. Books are considered to be perfect, and at least expected to be. Personally I hate to find broken or misleading information in the books that I read, because I tend to trust that the book has been scrutinized before it has been published. And if I find errors from the very beginning I usually don't continue reading the book at all, since I don't want to be misleaded. (Of course I'm talking about books I try to learn something new from. If I read a book which talks about stuff familiar to me, I usually submit corrections to the author/publisher) If we get to the point where we mistrust the printed information, that will be very bad. And latest rush of the many publishers to print early and often is a very bad trend, since the quality of the books gets very very bad. (This is very different from the open source motto of releasing early and often, since those releases aren't considered stable/perfect). Luckily ORA books are still keeping a high profile. I hope they stay that way. Of course there is an issue of constant evolvement of the sw products which makes the books outdated, even before their get to the book shelves, therefore I believe that the feature is in the e-books, but we aren't there yet for various reasons. Finally, our book went through a major rewrite of the guide, and while you might still not notice a difference from the guide in many place, it's because I've placed those changes back into the guide. So the recent versions of the guide have lots of information which is new and never has been reviewed. That's why we need many eyes, of both experienced and non-experienced programmers and users to make all the bugs in the book shallow. So when the book gets published it will bring more people into mod_perl community and
Re: Read file at startup, access data during request?
On Thu, 29 Mar 2001, Richard Anderson wrote:
I want to read and parse a file when Apache mod_perl starts and have access to the
data while my mod_perl methods are processing the request. The most obvious approach
(to me) is to put the reading/parsing code at the beginning of my mod_perl module,
outside of my methods, and load the data into a package array variable that my
methods can access during request processing.
However, I want to put the pathname of the file (relative to ServerRoot) in the
httpd.conf file as a PerlSetVar. I don't see any way to access the value of a
PerlSetVar until the request phase. In other words, in the module code that runs at
startup time, I want to do this:
my $file = $r-server_root_relative($r-dir_config('SharedSecretKeyFile'));
except I don't have the Apache Request object ($r).
Am I completely on the wrong track? Is there some way to access a PerlSetVar
without the request object?
How about this: httpd.conf:
Perl
use My::Preload;
My::Preload::init('SharedSecretKeyFile');
/Perl
But you can do this as well:
my $s = Apache-server;
my $file = $s-dir_config('SharedSecretKeyFile');
The former seems simpler to me...
and it's pretty much all in the guide :)
_
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: books reviewing (was Re: PerlRestartHandler)
OK, I do agree in principal (that it's important for the book to be the best that it can be). Although my post was really meant to be reassuring rather than saying that people shouldn't bother pitching in. I think the mod_perl guide is great. Yes, there may be inaccuracies in there (I haven't read it recently from cover to cover to say what those may be), but it's still better than ActiveState, Velocigen, JRun, ServletExec, NSAPI guide or any other commercial web app environment docs I have ever seen. In other words, while I applaud your efforts to be perfect because you care so much about open source -- your message seemed to be a bit stressed (eg going on about having to work together to beat the corporate sharks). The fact is that there will be inaccuracies which are uncovered later no matter how many people read the guide. Because that's just how it is. So while I think the goal to be perfect is great, I think you have already surpassed the intermediate goal of being better than commercial documentation for similar web application environments. With that said -- I do think its important for everyone to pitch in and read the book (and hopefully learn stuff along the way or discover bugs) which is why I am doing it. Because I do agree with pitching in to make it as good as possible. Well, anyway... Thanks, Gunther PS Thanks for posting my belly dancing pic... I needed that. :) At 11:02 AM 3/30/2001 +0800, Stas Bekman wrote: On Fri, 30 Mar 2001, Gunther Birznieks wrote: At 06:44 PM 3/29/01 +0800, Stas Bekman wrote: Indeed, I've often wished O'Reilly would provide book sources for people that have bought the treebook. Manning has something like that, you can buy the ebook cheaper than the actual book, and then if you decide to buy the treebook it's that much cheaper. I agree. Meanwhile you can always get the source by helping others to review books :) /me goes off to read a certain book which he'd promised to review but hasn't quite finished... make sure to grab the latest version of the sources though, we have done lots of small patches in the last days... I wish others who have promised to help to review the book were actually helping us :( We gotta release it asap, but the book was hardly touched by reviewers... I guess we will just release it as it is... don't be surprised if there will be some glitches in it... what can we do... You shouldn't worry so much. Considering that the mod_perl guide was an open source effort in the first place, I suspect the book will have already been quite well reviewed even if you've added a lot. I do worry about it. The guide was many time considered as having the ultimately correct information, and some of the broken stuff has been revealed years after it was placed there. People were taking things for granted, instead of getting the information scrutinuzed. Definitely the information there had been corrected many times, but it has too much information for me to feel calm that most of it correct. Our first book 7 years ago has a really stupid Y2K bug (stupid because the code says it takes Y2K into account and then goes on to not...) and oh yeah, some race condition in some of the file-based locking code...and ... we didnt use taint mode... and... files were opened without explicit and operators...and In the end though, for the audience of our book, we had gotten much more praise than flames. The important thing was that we released something to enable people to start coding web apps that were very highly documented relative to other free web apps written in Perl. And regardless of the quality -- still *at the time*, higher quality than many other free web apps. So in the end, I think we would have done a disservice by vetting the book more technically and waiting another year than the way we did it -- just release it. You see, for us, there is no such a thing as "good enough". We are open source people and compared to commercial bodies who are willing to releases unfinished products because there are just good enough and better than their competitors, we don't accept that. We want to code and documentation be perfect, and we aren't ready to release the final version of it claiming it to be a final version before it's perfect. That's why the mod_perl guide and other online documentation projects are great. Because it has never been claimed to be perfect, it's going through the constant change. And one should never consider it to be ultimately correct. It's in the constant beta version. Things are very different with deadtree versions of the documentation. It's parallel to a product release. Books are considered to be perfect, and at least expected to be. Personally I hate to find broken or misleading information in the books that I read, because I tend to trust that the book has been scrutinized before it has been published.
PerlAccessHandler causes '500 Server Error' on 'return OK'
Hi. I'm trying some of the well-known Apache-Perl-Modules, such as DayLimit.pm. Strangely, the server throws an internal error (500), when the Perl module returns 'OK'. The same is with 'DECLINED'. FORBIDDEN works well, AUTH_REQUIRED works also (though it doesn't make sense in the access control stage). I do not see anything in my error_log. The problem seems to be specific to the PerlAccessHandler Other Handlers (e.g.the PerlAuthenHandler) work fine: when returning OK, the page is displayed. Any ideas? Info: apache-1.3.19, mod_perl-1.25, perl5.005_03, OS: BSD/OS 4.1 Greetings, ~~~:-Jochen Schnapka
Strange Problem with opendir / readdir
Hi!
I have strange problems while using opendir / readdir
under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache
and not a Mason Bug.
I have no problem to run the same directly from the shell.
Is there a known bug?
Kind regards
Cornelius Kuschnereit
Environement:
Apache 1.3.19
modperl 1.25
mason 1.01
RedHat 7.0
reiserfs
--
test1_opendir.html
my little test:
--
%init
my $directory = qq[/usr/local/apache];
my $dir;
my @dirs= ();
opendir( DIR, $directory );
@dirs = readdir( DIR );
close( DIR );
/%init
Test - BR
% foreach $dir (sort @dirs) {
file:% $dir %
% }
BR
--
the (wrong) result:
--
Test - BR
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
file:
BR
--
--
test1_opendir.pl
my little (working) test:
--
#!/usr/bin/perl
my $directory = qq[/usr/local/apache];
my $dir;
my @dirs= ();
opendir( DIR, $directory );
@dirs = readdir( DIR );
close( DIR );
print "Test - \n";
foreach $dir (sort @dirs) {
print "file: $dir\n";
}
print "\n";
--
the (right) result:
--
Test -
file: .
file: ..
file: bin
file: cgi-bin
file: conf
file: htdocs
file: htdocs_mason_data_cache
file: icons
file: include
file: libexec
file: logs
file: man
file: perlmod
file: proxy
--
Re: Strange Problem with opendir / readdir
On Fri, 30 Mar 2001, Cornelius Kuschnereit wrote: Hi! I have strange problems while using opendir / readdir under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache and not a Mason Bug. I have no problem to run the same directly from the shell. Is there a known bug? A known bug: http://forum.swarthmore.edu/epigone/modperl/landchoigrerm :( _ 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/
[OT] Re: Strange Problem with opendir / readdir
Cornelius Kuschnereit wrote: opendir( DIR, $directory ); opendir( DIR, $directory ) or die "Can't read $directory because of $!";
ChildInitHandler
Hello!
The following code doesn't work. I think that child_init_handler is
never called. But there are no errors in the error log.
What goes wrong here?
-[/home/nikratio/cvs/tsession-perl/Apache/foo.pm]
#!/usr/bin/perl -w
package Apache::foo;
use Apache::Cookie ();
use Apache::Constants ':response';
use Apache::Util qw(:all);
use Apache::Log;
use strict;
sub child_init_handler($$)
{
my($this,$r) = @_;
$r-log_error("Session Manager initialized");
return OK;
}
sub child_exit_handler($$)
{
my($this,$r) = @_;
$r-log_error("Session Manager initialized");
return OK;
}
1;
--[apache config]---
Perl
BEGIN {
push @INC, "/home/nikratio/cvs/tsession-perl";
}
/Perl
PerlModule Apache::TSession
PerlModule Apache::foo
PerlChildInitHandler Apache::foo-child_init_handler()
PerlChildExitHandler Apache::foo-child_exit_handler()
...
--[error log]-
[Fri Mar 30 15:23:30 2001] [notice] SIGUSR1 received. Doing graceful restart
[Fri Mar 30 15:23:31 2001] [notice] FastCGI: wrapper mechanism enabled (wrapper:
/usr/lib/apache/suexec)
[Fri Mar 30 15:23:31 2001] [notice] FastCGI: process manager initialized (pid 19827)
[Fri Mar 30 15:23:32 2001] [notice] Apache/1.3.14 (Unix) Debian/GNU mod_fastcgi/2.2.10
mod_ssl/2.7.1 OpenSSL/0.9.6 mod_perl/1.24_01 PHP/4.0.4pl1 configured -- resuming
normal operations
[Fri Mar 30 15:23:32 2001] [notice] suEXEC mechanism enabled (wrapper:
/usr/lib/apache/suexec)
[Fri Mar 30 15:23:54 2001] [error] [client 127.0.1.1] client denied by server
configuration: /home/nikratio/Projekte/net-control.org/public/..
EOF
Thanks in advance,
- Nikolaus
--
"de.alt.comp.kdeDumm und trotzdem UNIX verwenden? KDE ist die Loesung."
Sven Paulus in 67hu21$43r$[EMAIL PROTECTED]
[OT] Re: Strange Problem with opendir / readdir
Cornelius Kuschnereit wrote:
@dirs = readdir( DIR );
foreach $dir (sort @dirs) {
next unless -d "directory/$dir";
print "file: $dir\n";
}
Re: Strange Problem with opendir / readdir
On Fri, 30 Mar 2001, Cornelius Kuschnereit wrote: I have strange problems while using opendir / readdir under MasonHQ. I'm not shure, but it seems to be a perl / modperl / Apache and not a Mason Bug. I have no problem to run the same directly from the shell. Is there a known bug? As far as I can tell, it's a mod_perl, glibc2.2 compatibility bug. - Paul
RE: [Mason] Strange Problem with opendir / readdir
Yes! I can see all Files and Dirs without . and .. Can this be a hint why readdir dosn't work? Thanx! Cornelius -- the (right) result: -- Test -x BR 1 file:"/usr/local/apache/bin" length of filename:21BR 2 file:"/usr/local/apache/cgi-bin" length of filename:25BR 3 file:"/usr/local/apache/conf" length of filename:22BR 4 file:"/usr/local/apache/htdocs" length of filename:24BR 5 file:"/usr/local/apache/htdocs_mason_data_cache" length of filename:41BR 6 file:"/usr/local/apache/htdocs_mason_data_cache2" length of filename:42BR 7 file:"/usr/local/apache/icons" length of filename:23BR 8 file:"/usr/local/apache/include" length of filename:25BR 9 file:"/usr/local/apache/libexec" length of filename:25BR 10 file:"/usr/local/apache/logs" length of filename:22BR 11 file:"/usr/local/apache/man" length of filename:21BR 12 file:"/usr/local/apache/perlmod" length of filename:25BR 13 file:"/usr/local/apache/proxy" length of filename:23BR BR Does glob() work? my @files = glob( "$directory/*" );
Shared memory between child processes
I understand the forking model of Apache, and what that means in terms of data initialized in the start-up phase being ready-to-go in each child process. But what I need to do is manage it so that a particular value is shared between all children, such that changes made by one are recognized by the others. In a simple case, imagine wanting to count how many times total the given handler is invoked. Bumping a global counter will still be local to the given child process, and if part of the handler's interface is to report this counter value, then the reported number is going to be dependent upon which child answers the request. I'm needing to implement a handler that uses a true Singleton pattern for the class instance. One per server, not just one per process (or thread). Randy -- --- Randy J. Ray | Buy a copy of a baby naming book and you'll never be at a [EMAIL PROTECTED] | loss for variable names. Fred is a wonderful name, and easy +1 408 543-9482 | to type. --Roedy Green, "How To Write Unmaintainable Code"
Re: Shared memory between child processes
At 5:30 PM -0800 3/30/01, Randy J. Ray wrote: I understand the forking model of Apache, and what that means in terms of data initialized in the start-up phase being ready-to-go in each child process. But what I need to do is manage it so that a particular value is shared between all children, such that changes made by one are recognized by the others. In a simple case, imagine wanting to count how many times total the given handler is invoked. Bumping a global counter will still be local to the given child process, and if part of the handler's interface is to report this counter value, then the reported number is going to be dependent upon which child answers the request. I'm needing to implement a handler that uses a true Singleton pattern for the class instance. One per server, not just one per process (or thread). You'll need to use some form of persistance mechanism such as a database, file, or perhaps (assuming you're on a Unix system) something like System V shared memory or semaphores. One quick 'n cheap way to implement mutual exclusion between Unix processes (executing on the same processor) is to use mkdir, which is atomic (ie once a process requests a mkdir, the mkdir will either be done or rejected before the requesting process is preempted by any other process). So you can do mkdir "xyz" if "xyz" already exists, wait or return an error read or write shared variable on disc rmdir "xyz" to guarantee that only one process at a time can be trying to access a disc file. There are many possible variations on this theme.
Re: Shared memory between child processes
Hello, RRI'm needing to implement a handler that uses a true Singleton pattern for RRthe class instance. One per server, not just one per process (or thread). SLYou'll need to use some form of persistance mechanism such as a SLdatabase, file, or perhaps (assuming you're on a Unix system) SLsomething like System V shared memory or semaphores. You can find more information on maintaining server-side state in the mod_perl guide or from the mod_perl book (at perl.apache.org and www.modperl.com, respectively). SLOne quick 'n cheap way to implement mutual exclusion between Unix SLprocesses (executing on the same processor) is to use mkdir, which is SLatomic (ie once a process requests a mkdir, the mkdir will either be SLdone or rejected before the requesting process is preempted by any SLother process). IMO, this is sort of cumbersome; on a single processor, you can just use advisory file locking. It's when you get onto NFS mounted systems with high concurrency that you have to muck with rolling your own mutexes (I find I usually use atomic move for that purpose). But on a single system, use flock() and a known lockfile, or sysopen with O_CREAT|O_EXCL if you can't put the file there beforehand. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
mod_perl forgets filled global variables
Hi, my name is Werner Schmidt-Wilczek, i am a programmer at the Policegovernment in Nuremberg, Bavaria, Germany. I am using mod_perl for our Intranet. The performance is great, but there are many sideeffects! An example: I have a database with 5 items. I load this items one time in a hour in a array named ARTIKEL. The array ARTIKEL ist declared in /usr/inclued/apache/modules/perl/startup.perl - i think its global an correct in this way - all users can search in this array. But sometimes it seams mod_perl has forgotten the array. I call my script 4,5... times, it runs correct but perhaps it has forgotten all the global filled variables - what happens. I called the Dumper \@ARTIKEL and he says the array is filled, but next time the array is empty - what is my failure??? Please help me I am looking forward to your answer with greetings Werner Schmidt-Wilczek
