Apache::SizeLimit, unshared RAM idea

[Joshua Chamas]

OK ...

So I had a mini-revelation about how to do max unshared RAM
for Apache::SizeLimit ... couldn't you register a 
child_init handler that calculated the processes size
post fork, then the unshared size would be

  UNSHARED_SIZE = CURRENT_SIZE - CHILD_INIT_SIZE

Voila!

OK, so what happen if other things happen in ChildInit
phase that bloat your process, like an Apache::DBI connect,
before your Apache::SizeLimit can try to calculate 
current size?  I guess you just have to make sure it
runs first, is this too hard from Apache::SizeLimit's
perspective?

-- Josh

Re: perl calendar application

[melo]

On Sat, Jan 06, 2001 at 12:28:01PM -0500, Blue Lang wrote:
> On Sat, 6 Jan 2001 [EMAIL PROTECTED] wrote:
> 
> Eh, I'm prepared to take my lynching, but I'd just like to remind everyone
> that there's nothing at all wrong with using PHP for things like this.
> You'll never be a worse person for learning something new, and the
> overheard required to manage a php+perl enabled apache is only minimally
> more than managing one or the other.
> 
> IMHO, it's just lame to rewrite something for which there exists dozens of
> good apps just because of the language im which it is written. You might
> as well be arguing about GPL/BSD/Artistic at that point.

I'm not lynching... :) just another point of view.

There is no problem in having several solutions for the same problem. It's
competition and it's good.

Sometime e rewrite something I saw in PHP or other language because:
 1. although I know php, i'm more fluent and faster in perl;
 2. perl is fun, so i'm having fun, when programming perl :)
 3. reimplementing something makes you think about the problem, and the
solution to the problem.  You get to know the problem better.

I do use application in php and other languages, but sometimes... :)

-- 
Pedro Melo Cunha - <[EMAIL PROTECTED]>
Novis - Dir. Rede - ISP - Infraes. Portal 
Ed. Atrium Saldanha - Pça. Dq. Saldanha, 1 - 7º / 1050-094 Lisboa
tel:  +351 21 0104340  - Fax: +351 21 0104301

Apache::SizeLimit for unshared RAM ???

[Joshua Chamas]

Hey,

I like the idea of Apache::SizeLimit, to no longer worry about
setting MaxRequestsPerChild.  That just seems smart, and might
get maximum usage out of each Apache child.

What I would like to see though is instead of killing the 
child based on VmRSS on Linux, which seems to be the apparent
size of the process in virtual memory RAM, I would like to
kill it based on the amount of unshared RAM, which is ultimately
what we care about.

Here's why: any time I add a new module to the code base, 
I am going to grow the RAM of all processes when I preload
them with PerlModule or use in startup.pl, but I DON'T CARE
about those, because they are shared, right?  Problem is
I do care because I have to retweak the Apache::SizeLimit
every time my code base grows, because my RAM of each process
just grew at the post fork baseline.

I guess you could say, SO WHAT!, get over it, but it seems
like there should be a better way.  * Dreamy *

-- Josh

Re: Configtest yields bad news...

[andrewl]

Good morning,  Ged and modperl list,
I used the below provided argument listing (or so I believe).  This must be
executed automatically by the perl Makefile.PL routine?
I tried it once as you sent it, and once with the change listed to the
APACHE_SRC default directoy.  Both times, I got the following exact same
error:  (I did make clean in between attempts to compile).  Possibly I have
to use a separate APACHE_SRC directory?

-
.
.
modules/src.. Use of uninitialzed value in concatenation (.) at
modules/src.t line 27.
.
.
Failed test TotatFailed
modules/src.t  63
3 tests skipped
httpd terminated
Failed 1/34 test scripts.  97.06% okay.  5/388 subtests failed 98.71% okay.
make: *** [run_tests] Error 29
---

Thanks for your help.
Perl 5.6.0
Linux 2.2.16
Apache 1.3.14
mod_perl 1.24_01

Andrew Lietzow
Plantsman
Wannabe hacker?



"G.W. Haywood" wrote:

> > I've attached a makepl_args.mod_perl
>
> Ged
>   
> USE_APACI=1
> APACHE_PREFIX=/usr/local
> APACHE_SRC=../apache_1.3.9/src  --- changed this to ../apache/src (my
> current apache directory)
> DO_HTTPD=1   can change this to
> ../apache_1.3.14/src if that makes sense but the vast majority of
> EVERYTHING=1the contents in these two
> directories is the same.
> ALL_HOOKS=1
> PERL_SSI=1
> PERL_SECTIONS=1
> ADD_MODULE=info,status,proxy
> APACI_ARGS=--sbindir=/usr/local/sbin/httpd_perl
> APACI_ARGS=--sysconfdir=/usr/local/apache/httpd_perl/conf
> APACI_ARGS=--runtimedir=/usr/local/apache/httpd_perl/run
> APACI_ARGS=--logfiledir=/usr/local/apache/httpd_perl/logs
> APACI_ARGS=--localstatedir=/usr/local/apache/httpd_perl/stat
> APACI_ARGS=--proxycachedir=/usr/local/apache/httpd_perl/proxy
> APACI_ARGS=--enable-module=rewrite
> APACI_ARGS=--enable-module=include
> APACI_ARGS=--enable-module=info

Erro 127

[Elman Vagif Abdullaev]

Hey all,
I am having this error 127, which says that argument list is too
long when I try to run make to install mod_perl. Does anyone knows how to
solve it? Thanks.

Re: mod-perl on Solaris 2.6

[David McCabe]

> From: Jeff Beard <[EMAIL PROTECTED]>
> Date: Mon, 08 Jan 2001 12:48:58 -0700 (MST)
> Subject: Re: mod-perl on Solaris 2.6
> 
> Check out the mailing list archive for something I posted
> a while back. It boiled down to not using GNU binutils for
> anything. Including GCC.
 
Partly, I agree. Gcc is fine for Solaris 2.5, 7 and 8, if you use the package from
sunfreeware.com, and install all relevant patches. Don't use any other gnu bintools
though, especially not the linker. (Well, at least not with a "stock" Solaris system.
:) I have been building perl for years with that combo, and mod_perl/Apache for just
over a year, and while it does require that you know what you are doing, (and it
certainly sounds like Siddhartha does), it always works fine for me.

Siddhartha, have you tried the $HOME/.makepl_args.mod_perl file-method to build
mod_perl/Apache?? If you set this file up properly, you can build/install
mod_perl/Apache with the standard:

perl Makefile.pl
make
make test
make install

all from within the mod_perl distribution dir. This is documented in the INSTALL
document of the mod_perl distribution, and there is a commented sample/template in
eg/makepl_args.mod_perl (note there is no leading . here) of the distribution. (And
once Doug relases another version of mod_perl with no _ in the version number, you
will be able to do "install mod_perl" from the CPAN shell, which downloads and builds
the latest versions of everything, hopefully:)

Also, make sure your LD_LIBRARY_PATH and PATH vars are set properly. (I have never
had to use the LD_PRELOAD var, and I build a lot of software for Solaris from C
source) If you use tcsh, (or any shell that supports it) try "which perl" and "which
gcc", and "whereis perl" and "whereis gcc", and make sure that you are really getting
what you think. And make sure that any sym-links/links (like maybe /usr/bin/perl)
point to where you want them. I always try to make sure that my build environments
can only see what I want them to see, and no other versions of anything.

One other thing, look at the output of perl -V, and see if the flags to gcc for
building perl are the same as what are being passed to gcc for building
mod_perl/Apache. They should be, but something might be screwing them up in your
enviornment, so check anyway. :)



David McCabe  Unix System Administrator
Le Groupe Videotron [EMAIL PROTECTED]   (514) 380 4433

"We've all heard that a million monkeys banging 
on a million typewriters will eventually reproduce 
the works of Shakespeare. Now, thanks to the 
Internet, we know this is not true."
   - Robert Wilensky UCB

Re: mod_perl-1.24 / apache-1.3.14 problem

[Doug MacEachern]

On Mon, 8 Jan 2001, Vivek Khera wrote:
 
> Are there any showstoppers in 1.24_02-dev that need addressing or
> should we just roll this out as 1.25?  I have no problems with it.

well, there are some hpux-dso issues i am going to fix before 1.25.  i
would also like to catch up on what's left in my modperl mail folder to
see if anything else obvious needs fixing.  i'm hoping to have 1.25 ready
this week.

Re: mod_perl / Apache::SSI problems

[Ken Williams]

[EMAIL PROTECTED] (Tom Kralidis) wrote:
>Ken,
>
>Quick (additional) question:
>
>How do I pick up args in my module, ie, in test.phtml:
>
>
>
>...here's the subroutine in TomSSI.pm:
>
>sub getScripts {
>  my $path = '/www/htdocs/gis/';
>
>  # thought this would pick up the arg
>  # my $project = $_[0];
>  # it didn't (null), so I hardcoded below just to see that all works
>  # from the config end of things, works fine.
>
>  my $project = "avenue/ipcdiadsgn";

It looks like you're doing it correctly from what I can tell.  If you
don't mind editing SSI.pm, you could set $debug=1 and see what appears
in the error log.  It will show you what arguments it thinks it's
passing to your subroutine.

Does using 'args' instead of 'arg' work?  They should both work, as
described in the docs.

Make sure you're not getting confused between TomSSI and Apache::TomSSI,
I've seen both names in your emails.


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum

Re: mod_perl / Apache::SSI problems

[Ken Williams]

Hi Tom,

You probably want something like this:

   PerlModule Apache::Filter
   PerlModule Apache::Footer
   PerlModule Apache::SSI
   PerlModule Apache::TomSSI
   
   
SetHandler perl-script
PerlHandler Apache::Footer
   
   
   
SetHandler perl-script
PerlHandler Apache::SSI Apache::Footer
Options +Includes
   

The mod_include module, and its 'server-parsed' handler, won't be
involved at all.  But Apache::SSI does respect the 'Includes' directive
to a certain extent.

I assume TomSSI contains some routines that you'll use from SSI
directives?  If so, it doesn't need to be a handler, nor does it need to
subclass Apache::SSI.


[EMAIL PROTECTED] (Tom Kralidis) wrote:
>Hi Ken,
>
>Thanks for the info.  I tried on files of type .phtml for testing and it 
>worked.
>
>   
>SetHandler perl-script
>PerlSetVar Filter On
>PerlHandler TomSSI Apache::Footer
>   
>
>Now, how to integrate this into httpd.conf?  I currently have this:
>
>  
>   AddHandler server-parsed .shtml
>   AddType text/html .shtml
>   Options +Includes
>  
>
>   PerlModule Apache::SSI
>   PerlModule Apache::Filter
>   PerlModule Apache::TomSSI
>
>   
>SetHandler perl-script
>PerlHandler Apache::Footer
>   
>
>How to modify so that .shtml takes it too?  I tried and no SSI came out, I tried commenting out the AddHandler server-parsed 
>lines and no luck.
>
>I *could* rename all my .shtml files to something unique as per my .phtml 
>testing, but that may be alot of work and changes as far as supporting 
>classic SSI, etc.
>
>Any way to do this?
>
>Thanks
>
>...Tom


  ------
  Ken Williams Last Bastion of Euclidity
  [EMAIL PROTECTED]The Math Forum

Best way to handle gobal hash assignment under Apache::ASP

[Aaron Johnson]

I have a configuration hash that controls all the aspects of my
application.

It is updated while the server is running so it needs to be "refreshed"
for all processes.

What is the best way to share it globally and insure that updates are
read by all processes?

I currently store the hash using the Storable module so it is always in
a hash ( well ok a hash reference ) format, that is no database access
or ini file to modify/keep track of.  When updates are made the hash is
saved in the Storable format.

I have tried some of the suggestions outlined by Stas on the Perl Month
web site, but I am getting inconsistent results. (
http://www.perlmonth.com/columns/perl_apache/perl_apache.html?issue=11 )

I need to have the values available inside of several preloaded modules
as well as at the page level.

The configuration file is working great, expect for having to reboot
when changes are made.

Aaron Johnson

Re: Caching search results

[Sander van Zoest]

On Mon, 8 Jan 2001, G.W. Haywood wrote:

> At the risk of getting shot down in flames again,
> do you think you could take this off-list guys?

I guess this could be moved to the scalable list ([EMAIL PROTECTED]),
or in private since this isn't really on the topic of modperl anymore.

Cheers,

--
Sander van Zoest [[EMAIL PROTECTED]]
Covalent Technologies, Inc.   http://www.covalent.net/
(415) 536-5218 http://www.vanzoest.com/sander/

Re: Caching search results

[G.W. Haywood]

Hi Guys,

On Mon, 8 Jan 2001, Sander van Zoest wrote:

> On Mon, 8 Jan 2001, Perrin Harkins wrote:
> 
> > On Mon, 8 Jan 2001, Sander van Zoest wrote:

At the risk of getting shot down in flames again,
do you think you could take this off-list guys?
I can't seem to delete the messages as fast as
they're coming in... :)

73,
Ged.

Re: Caching search results

[Sander van Zoest]

On Mon, 8 Jan 2001, Perrin Harkins wrote:

> On Mon, 8 Jan 2001, Sander van Zoest wrote:
> > > starters. A dbm would be fine too, but more trouble to purge old entries
> > > from.
> > You could always have a second dbm file that can keep track of TTL issues
> > of your data keys, so it would simply be a series of delete calls.
> > Granted you would have another DBM file to maintain.
> I find it kind of painful to trim dbm files, because most implementations
> don't relinquish disk space when you delete entries.  You end up having to
> actually make a new dbm file with the "good" contents copied over to it in
> order to slim it down.

Yeah, this is true. Some DBMs have special routines to fix these issues.  
You could use the gdbm_reorganize call to clean up those issues for 
example (if you are using gdbm that is)

Just some quick pseudo code (don't have a quick example ready here):

use GDBM_File;

my $gdbm = tie %hash, 'GDBM_File', 'file.gdbm' &GDBM_WRCREAT|&GDBM_FAST, 0640 
   or die "$!";

$gdbm->reorganize;

That definately helps a lot.

--
Sander van Zoest [[EMAIL PROTECTED]]
Covalent Technologies, Inc.   http://www.covalent.net/
(415) 536-5218 http://www.vanzoest.com/sander/

Re: Caching search results

[Sander van Zoest]

On Mon, 8 Jan 2001, Simon Rosenthal wrote:

>   I couldn't see writing a daemon as you suggested  offering us any 
> benefits under those circumstances, given that RDBMS access is built into 
> Apache::Session.

No, in your case I do not see a reason behind it either. ;-)
Again this shows that it all depends on the requirements and things you
are willing to sacrafice.

Cheers,

--
Sander van Zoest [[EMAIL PROTECTED]]
Covalent Technologies, Inc.   http://www.covalent.net/
(415) 536-5218 http://www.vanzoest.com/sander/

Re: Caching search results

[Perrin Harkins]

On Mon, 8 Jan 2001, Sander van Zoest wrote:
> > starters. A dbm would be fine too, but more trouble to purge old entries
> > from.
> 
> You could always have a second dbm file that can keep track of TTL issues
> of your data keys, so it would simply be a series of delete calls.
> Granted you would have another DBM file to maintain.

I find it kind of painful to trim dbm files, because most implementations
don't relinquish disk space when you delete entries.  You end up having to
actually make a new dbm file with the "good" contents copied over to it in
order to slim it down.

- Perrin

Re: Caching search results

[DeWitt Clinton]

On Mon, Jan 08, 2001 at 10:10:25AM -0800, Perrin Harkins wrote:

> Always start with CPAN.  Try Tie::FileLRUCache or File::Cache for
> starters. A dbm would be fine too, but more trouble to purge old
> entries from.

If you find that File::Cache works for you, then you may also want to
check out the simplified and improved version in the Avacet code,
which additionally offers a unified service model for mod_perl
applications.  Services are available for templates (either Embperl or
Template Toolkit), XML-based configuratio, object caching, connecting
to the Avacet application engine, standardized error handling,
dynamically dispatching requests to modules, and many other things.

-DeWitt

Re: Caching search results

[Sander van Zoest]

On Mon, 8 Jan 2001, Simon Rosenthal wrote:

> an RDBMS is not much more trouble to purge, if you have a 
> time-of-last-update field. And if you're ever going to access your cache 
> from multiple servers, you definitely don't want to deal with  locking 
> issues for DBM and filesystem based solutions ;=(

RDBMS does bring replication and backup issues. The DBM and FS solutions
definately have their advantages. It would not be too difficult to write
a serialized daemon that makes request over the net to a DBM file.

What in you experience makes you pick the overhead of an RDBMS for a simple
cache in favor of DBM, FS solutions?
  
--
Sander van Zoest [[EMAIL PROTECTED]]
Covalent Technologies, Inc.   http://www.covalent.net/
(415) 536-5218 http://www.vanzoest.com/sander/

Re: Caching search results

[Simon Rosenthal]

At 02:02 PM 1/8/01 -0800, Sander van Zoest wrote:
>On Mon, 8 Jan 2001, Simon Rosenthal wrote:
>
> > an RDBMS is not much more trouble to purge, if you have a
> > time-of-last-update field. And if you're ever going to access your cache
> > from multiple servers, you definitely don't want to deal with  locking
> > issues for DBM and filesystem based solutions ;=(
>
>RDBMS does bring replication and backup issues. The DBM and FS solutions
>definately have their advantages. It would not be too difficult to write
>a serialized daemon that makes request over the net to a DBM file.
>
>What in you experience makes you pick the overhead of an RDBMS for a simple
>cache in favor of DBM, FS solutions?

We cache user session state  (basically using Apache::Session) in a small 
(maybe 500K records) mysql database , which is accessed by multiple web 
servers. We made an explicit decision NOT to replicate or backup this 
database - it's very dynamic, and the only user visible consequence of a 
loss of the database would be an unexpected login screen - we felt this was 
a tradeoff we could live with.  We have a hot spare mysql instance which 
can be brought into service immediately, if required.

  I couldn't see writing a daemon as you suggested  offering us any 
benefits under those circumstances, given that RDBMS access is built into 
Apache::Session.

I would not be as cavalier as this if we were doing anything more than 
using the RDBMS as a fast cache. With decent hardware (which we have - Sun 
Enterprise servers  with nice fast disks and enough memory) the typical 
record retrieval time  is around 10ms, which  even if slow compared to a 
local FS access is plenty fast enough in the context of the processing we 
do for dynamic pages.

Hope this answers your question.

-Simon



>
>--
>Sander van Zoest [[EMAIL PROTECTED]]
>Covalent Technologies, Inc.   http://www.covalent.net/
>(415) 536-5218 http://www.vanzoest.com/sander/

-
Simon Rosenthal ([EMAIL PROTECTED])  
Web Systems Architect
Northern Light Technology
One Athenaeum Street. Suite 1700, Cambridge, MA  02142
Phone:  (617)621-5296  :   URL:  http://www.northernlight.com
"Northern Light - Just what you've been searching for"

Re: Caching search results

[Sander van Zoest]

On Mon, 8 Jan 2001, Perrin Harkins wrote:

> Bill Moseley wrote:
> > Anyway, I'd like to avoid the repeated queries in mod_perl, of course.  So,
> > in the sort term, I was thinking about caching search results (which is
> > just a sorted list of file names) using a simple file-system db -- that is,
> > (carefully) build file names out of the queries and writing them to some
> > directory tree .  Then I'd use cron to purge LRU files every so often.  I
> > think this approach will work fine and instead of a dbm or rdbms approach.
> Always start with CPAN.  Try Tie::FileLRUCache or File::Cache for
> starters. A dbm would be fine too, but more trouble to purge old entries
> from.

You could always have a second dbm file that can keep track of TTL issues
of your data keys, so it would simply be a series of delete calls.
Granted you would have another DBM file to maintain.

--
Sander van Zoest [[EMAIL PROTECTED]]
Covalent Technologies, Inc.   http://www.covalent.net/
(415) 536-5218 http://www.vanzoest.com/sander/

Re: mod-perl on Solaris 2.6

[Siddhartha Jain]

Is the answer using LD_PRELOAD? But i remember having compiled successfully
on Solaris 7 x86. Anyway, please tell me if there is anyway other than using
the LD_PRELOAD option.

Siddhartha

- Original Message -
From: "Jeff Beard" <[EMAIL PROTECTED]>
To: "Siddhartha Jain" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 09, 2001 1:18 AM
Subject: Re: mod-perl on Solaris 2.6


> Check out the mailing list archive for something I posted
> a while back. It boiled down to not using GNU binutils for
> anything. Including GCC.
>
> --Jeff
>
> --
> Jeff Beard
> _
> Web: www.cyberxape.com
> Email: jeff at cyberxape dot com
> Earth: Boulder, CO, USA
>
> On Mon, 8 Jan 2001, Siddhartha Jain wrote:
>
> > Hi,
> >
> > I have been trying to compile mod-perl (various 1.21 to 1.24_01 ) on
Solaris
> > 2.6 with apache (various 1.3.11 to 1.3.14) with perl-5.005003 and also
> > perl-5.6. If i compile it statically, i get a core dump on running
apache
> > and if i compile it via apxs, i get a "Symbol not found main, in
libperl.so"
> > error. I had compiled perl-5.6 using Solaris's malloc and later i
compiled
> > perl-5.005 with perl's malloc but nothing helped. I am mostly at my wits
> > ends having tried all sorts of combinations. Could someone help me?
> >
> > Siddhartha Jain
> >
>
>

RE: [ANNOUNCE] Apache-AuthenLDAP 0.52

[Geoffrey Young]

> -Original Message-
> From: Christian Gilmore [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 08, 2001 2:24 PM
> To: 'Geoffrey Young'; 'Modperl Mailing List (E-mail)'
> Subject: RE: [ANNOUNCE] Apache-AuthenLDAP 0.52
> 
> 
> Yup, but according to Doug, the patch committed to fix the 
> set_handlers
> problems is not slated to enter production until 1.26 is 
> released. 1.25
> will not contain the patch. You'd have to ask Doug why.

I could have sworn that those fixes made it in to 1.24_01 - I've stopped
having problems with get/set_handlers and coderefs since then...

I think I remember the stuff you reported back then - it's still not fixed?

anyway, my cvs box is being moved, so I can't even look at Changes...

--Geoff

> 
> Regards,
> Christian
> 

Re: mod-perl on Solaris 2.6

[Jeff Beard]

Check out the mailing list archive for something I posted
a while back. It boiled down to not using GNU binutils for
anything. Including GCC.

--Jeff

--
Jeff Beard
_
Web:www.cyberxape.com
Email:  jeff at cyberxape dot com
Earth:  Boulder, CO, USA

On Mon, 8 Jan 2001, Siddhartha Jain wrote:

> Hi,
>
> I have been trying to compile mod-perl (various 1.21 to 1.24_01 ) on Solaris
> 2.6 with apache (various 1.3.11 to 1.3.14) with perl-5.005003 and also
> perl-5.6. If i compile it statically, i get a core dump on running apache
> and if i compile it via apxs, i get a "Symbol not found main, in libperl.so"
> error. I had compiled perl-5.6 using Solaris's malloc and later i compiled
> perl-5.005 with perl's malloc but nothing helped. I am mostly at my wits
> ends having tried all sorts of combinations. Could someone help me?
>
> Siddhartha Jain
>

RE: [ANNOUNCE] Apache-AuthenLDAP 0.52

[Christian Gilmore]

Geoff,

Here's the relevant note from Doug last August.

Regards,
Christian

-Original Message-
From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 30, 2000 10:54 PM
To: Geoffrey Young
Cc: '[EMAIL PROTECTED]'
Subject: RE: $r->get_handlers bug/oversight?


i committed 2 small bits of the last patch, adding PerlCleanupHandler to
the {get,set}_handlers table and the $r->get_handler refcnt fix.  i put a
new version of the patch against cvs here:
http://perl.apache.org/~dougm/set_handlers.pat

similar to the last, but also deals with
$r->set_handlers(Perl*Handler => undef)

and also allows set_handlers() to change the handlers for the current
phase, something which did not work in the past.  one caveat though, the
number of new handlers passed to set_handlers() must be different from the
current number of handlers.  you can work around that by adding an extra
dummy DECLINED handler:

$r->set_handlers($callback => [\&DECLINED,
   \&one_handler,
   \&two_handler]);

it would be great to hear test results from the new patch, but in any case
it probably won't go in until after 1.25.

Re: Caching search results

[Simon Rosenthal]

At 10:10 AM 1/8/01 -0800, you wrote:
>Bill Moseley wrote:
> > Anyway, I'd like to avoid the repeated queries in mod_perl, of course.  So,
> > in the sort term, I was thinking about caching search results (which is
> > just a sorted list of file names) using a simple file-system db -- that is,
> > (carefully) build file names out of the queries and writing them to some
> > directory tree .  Then I'd use cron to purge LRU files every so often.  I
> > think this approach will work fine and instead of a dbm or rdbms approach.
>
>Always start with CPAN.  Try Tie::FileLRUCache or File::Cache for
>starters. A dbm would be fine too, but more trouble to purge old entries
>from.

an RDBMS is not much more trouble to purge, if you have a 
time-of-last-update field. And if you're ever going to access your cache 
from multiple servers, you definitely don't want to deal with  locking 
issues for DBM and filesystem based solutions ;=(

-Simon

-
Simon Rosenthal ([EMAIL PROTECTED])  
Web Systems Architect
Northern Light Technology
One Athenaeum Street. Suite 1700, Cambridge, MA  02142
Phone:  (617)621-5296  :   URL:  http://www.northernlight.com
"Northern Light - Just what you've been searching for"

RE: [ANNOUNCE] Apache-AuthenLDAP 0.52

[Christian Gilmore]

Yup, but according to Doug, the patch committed to fix the set_handlers
problems is not slated to enter production until 1.26 is released. 1.25
will not contain the patch. You'd have to ask Doug why.

Regards,
Christian

> -Original Message-
> From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 08, 2001 12:48 PM
> To: 'Christian Gilmore'; Modperl Mailing List (E-mail)
> Subject: RE: [ANNOUNCE] Apache-AuthenLDAP 0.52
>
>
>
>
> > -Original Message-
> > From: Christian Gilmore [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 08, 2001 12:52 PM
> > To: Modperl Mailing List (E-mail)
> > Subject: [ANNOUNCE] Apache-AuthenLDAP 0.52
> >
> > o  Better handled of pre-1.26 set_handlers bugs
>
> did I miss something - this is the second time someone has
> mentioned 1.26...
> is 1.25 not slated to be the next release?
>
> --Geoff
>

RE: [ANNOUNCE] Apache-AuthenLDAP 0.52

[Geoffrey Young]

> -Original Message-
> From: Christian Gilmore [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 08, 2001 12:52 PM
> To: Modperl Mailing List (E-mail)
> Subject: [ANNOUNCE] Apache-AuthenLDAP 0.52
>
> o  Better handled of pre-1.26 set_handlers bugs

did I miss something - this is the second time someone has mentioned 1.26...
is 1.25 not slated to be the next release?

--Geoff

Re: mod-perl on Solaris 2.6

[Siddhartha Jain]

And i tried every possible way given in the INSTALL.*

- Original Message -
From: "Danny Rathjens" <[EMAIL PROTECTED]>
To: "Siddhartha Jain" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 09, 2001 12:08 AM
Subject: Re: mod-perl on Solaris 2.6


> Siddhartha Jain wrote:
> >
> > Hi,
> >
> > I have been trying to compile mod-perl (various 1.21 to 1.24_01 ) on
Solaris
> > 2.6 with apache (various 1.3.11 to 1.3.14) with perl-5.005003 and also
> > perl-5.6. If i compile it statically, i get a core dump on running
apache
> > and if i compile it via apxs, i get a "Symbol not found main, in
libperl.so"
> > error. I had compiled perl-5.6 using Solaris's malloc and later i
compiled
> > perl-5.005 with perl's malloc but nothing helped. I am mostly at my wits
> > ends having tried all sorts of combinations. Could someone help me?
> >
> > Siddhartha Jain
>
> I just did this myself(migrating our cluster from linux to solaris(not by
choice)).
> I am using perl-5.6,apache_1.3.14, and mod_perl-1.24_01 on Solaris2.7
though.
>
> One thing to check is to make sure the same compiler is being used to
> compile all the various parts. (e.g. I installed gcc in /usr/local
> so I put /usr/local/bin first in my path, also made a symlink cc -> gcc)
>
> What commands did you use to configure?
> vanilla mod_perl, like this?:
> cd ../mod_perl-x.xx
> perl Makefile.PL DO_HTTPD=1 USE_APACI=1 EVERYTHING=1
APACHE_PREFIX=/usr/local/apache APACHE_SRC=../apache_1.3.14/src
> make
> --
> struct Programmer/Analyst 'Danny Rathjens' {this.place = "MyCity.com";}
> I know you believe you understood what you think I said, but I
> am not sure you realize that what you heard is not what I meant.
>

Re: mod-perl on Solaris 2.6

[Siddhartha Jain]

Okay ... the compiler i've been using all along is gcc-2.95.2. If i compile
only apache, it runs fine but if i add any kind of mod_perl, it crashes.

Siddhartha

- Original Message -
From: "Danny Rathjens" <[EMAIL PROTECTED]>
To: "Siddhartha Jain" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 09, 2001 12:08 AM
Subject: Re: mod-perl on Solaris 2.6


> Siddhartha Jain wrote:
> >
> > Hi,
> >
> > I have been trying to compile mod-perl (various 1.21 to 1.24_01 ) on
Solaris
> > 2.6 with apache (various 1.3.11 to 1.3.14) with perl-5.005003 and also
> > perl-5.6. If i compile it statically, i get a core dump on running
apache
> > and if i compile it via apxs, i get a "Symbol not found main, in
libperl.so"
> > error. I had compiled perl-5.6 using Solaris's malloc and later i
compiled
> > perl-5.005 with perl's malloc but nothing helped. I am mostly at my wits
> > ends having tried all sorts of combinations. Could someone help me?
> >
> > Siddhartha Jain
>
> I just did this myself(migrating our cluster from linux to solaris(not by
choice)).
> I am using perl-5.6,apache_1.3.14, and mod_perl-1.24_01 on Solaris2.7
though.
>
> One thing to check is to make sure the same compiler is being used to
> compile all the various parts. (e.g. I installed gcc in /usr/local
> so I put /usr/local/bin first in my path, also made a symlink cc -> gcc)
>
> What commands did you use to configure?
> vanilla mod_perl, like this?:
> cd ../mod_perl-x.xx
> perl Makefile.PL DO_HTTPD=1 USE_APACI=1 EVERYTHING=1
APACHE_PREFIX=/usr/local/apache APACHE_SRC=../apache_1.3.14/src
> make
> --
> struct Programmer/Analyst 'Danny Rathjens' {this.place = "MyCity.com";}
> I know you believe you understood what you think I said, but I
> am not sure you realize that what you heard is not what I meant.
>

Re: mod-perl on Solaris 2.6

[Siddhartha Jain]

Applying patches was the first thing i did after installing the OS (kind of
a standard practise with me). So, yes everything i've done has been after
installing the patches.

Siddhartha

- Original Message -
From: "Khachaturov, Vassilii" <[EMAIL PROTECTED]>
To: "'Siddhartha Jain'" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 09, 2001 12:02 AM
Subject: RE: mod-perl on Solaris 2.6


> Did you rebuild Perl since then?
>
> -Original Message-
> From: Siddhartha Jain [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 08, 2001 1:38 PM
> To: [EMAIL PROTECTED]
> Subject: Re: mod-perl on Solaris 2.6
>
>
> oh! Sorry, i didn't mention but i have already applied all the latest Sun
> recommended patches on the machine. Now what?
>

Re: mod_perl-1.24 / apache-1.3.14 problem

[Vivek Khera]

> "cr" == cliff rayman <[EMAIL PROTECTED]> writes:

cr> hmmm.  i checked CPAN about a month ago, and they
cr> had the new version.  i believe CPAN is actually a bunch of mirrored
cr> sites that the dns redirects to.  I wonder if the one you ended up
cr> getting is not getting properly mirrored?

But the CPAN shell doesn't see the _1 version because of the "_" in
the version number.  If you ask CPAN what the latest version is, you
find 1.24.

The file is there but the index doesn't tell you about it.

Are there any showstoppers in 1.24_02-dev that need addressing or
should we just roll this out as 1.25?  I have no problems with it.

Re: mod-perl on Solaris 2.6

[Danny Rathjens]

Siddhartha Jain wrote:
> 
> Hi,
> 
> I have been trying to compile mod-perl (various 1.21 to 1.24_01 ) on Solaris
> 2.6 with apache (various 1.3.11 to 1.3.14) with perl-5.005003 and also
> perl-5.6. If i compile it statically, i get a core dump on running apache
> and if i compile it via apxs, i get a "Symbol not found main, in libperl.so"
> error. I had compiled perl-5.6 using Solaris's malloc and later i compiled
> perl-5.005 with perl's malloc but nothing helped. I am mostly at my wits
> ends having tried all sorts of combinations. Could someone help me?
> 
> Siddhartha Jain

I just did this myself(migrating our cluster from linux to solaris(not by choice)).
I am using perl-5.6,apache_1.3.14, and mod_perl-1.24_01 on Solaris2.7  though.

One thing to check is to make sure the same compiler is being used to
compile all the various parts. (e.g. I installed gcc in /usr/local
so I put /usr/local/bin first in my path, also made a symlink cc -> gcc)

What commands did you use to configure?
vanilla mod_perl, like this?:
cd ../mod_perl-x.xx
perl Makefile.PL DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/usr/local/apache 
APACHE_SRC=../apache_1.3.14/src
make
-- 
struct Programmer/Analyst 'Danny Rathjens' {this.place = "MyCity.com";}
I know you believe you understood what you think I said, but I
am not sure you realize that what you heard is not what I meant.

RE: mod-perl on Solaris 2.6

[Khachaturov, Vassilii]

Did you rebuild Perl since then?

-Original Message-
From: Siddhartha Jain [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 08, 2001 1:38 PM
To: [EMAIL PROTECTED]
Subject: Re: mod-perl on Solaris 2.6


oh! Sorry, i didn't mention but i have already applied all the latest Sun
recommended patches on the machine. Now what?

Re: mod-perl on Solaris 2.6

[Siddhartha Jain]

oh! Sorry, i didn't mention but i have already applied all the latest Sun
recommended patches on the machine. Now what?

- Original Message -
From: "Jimi Thompson" <[EMAIL PROTECTED]>
To: "Siddhartha Jain" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, January 08, 2001 11:55 PM
Subject: Re: mod-perl on Solaris 2.6


> You need to run, do not walk, immediately to www.sun.com and apply all
> of the Solaris patches to your machine.
>
> Siddhartha Jain wrote:
> >
> > Hi,
> >
> > I have been trying to compile mod-perl (various 1.21 to 1.24_01 ) on
Solaris
> > 2.6 with apache (various 1.3.11 to 1.3.14) with perl-5.005003 and also
> > perl-5.6. If i compile it statically, i get a core dump on running
apache
> > and if i compile it via apxs, i get a "Symbol not found main, in
libperl.so"
> > error. I had compiled perl-5.6 using Solaris's malloc and later i
compiled
> > perl-5.005 with perl's malloc but nothing helped. I am mostly at my wits
> > ends having tried all sorts of combinations. Could someone help me?
> >
> > Siddhartha Jain

Re: mod-perl on Solaris 2.6

[Jimi Thompson]

You need to run, do not walk, immediately to www.sun.com and apply all
of the Solaris patches to your machine.

Siddhartha Jain wrote:
> 
> Hi,
> 
> I have been trying to compile mod-perl (various 1.21 to 1.24_01 ) on Solaris
> 2.6 with apache (various 1.3.11 to 1.3.14) with perl-5.005003 and also
> perl-5.6. If i compile it statically, i get a core dump on running apache
> and if i compile it via apxs, i get a "Symbol not found main, in libperl.so"
> error. I had compiled perl-5.6 using Solaris's malloc and later i compiled
> perl-5.005 with perl's malloc but nothing helped. I am mostly at my wits
> ends having tried all sorts of combinations. Could someone help me?
> 
> Siddhartha Jain

begin:vcard 
n:Thompson;Jimi
tel;pager:877-309-2784
tel;cell:817-980-7863
tel;work:817-619-3612
x-mozilla-html:FALSE
url:http://www.link.com
org:Link.com;Unix Team, IT
version:2.1
email;internet:[EMAIL PROTECTED]
title:Web Master
adr;quoted-printable:;;2200 Arlington Downs Rd =0D=0AMail Stop 148=0D=0A;Arlington;TX;76011;USA
fn:Jimi Thompson
end:vcard

Re: mod_perl-1.24 / apache-1.3.14 problem

[___cliff rayman___]

hmmm.  i checked CPAN about a month ago, and they
had the new version.  i believe CPAN is actually a bunch of mirrored
sites that the dns redirects to.  I wonder if the one you ended up
getting is not getting properly mirrored?

Mike Hanafey wrote:

> Thanks for the replies. Next time I will not go to CPAN for mod_perl...
>
> Mike Hanafey 
> DuPont Ag Products  |
> Delaware Technology Park, Suite 200/206 |
> 1 Innovation Way, PO BOX 6104   |
> Newark, DE 19714-6104   |
> Email: [EMAIL PROTECTED] Phone: (302)631-2608 Fax: (302)631-2607 ++

--
___cliff [EMAIL PROTECTED]http://www.genwax.com/

mod-perl on Solaris 2.6

[Siddhartha Jain]

Hi,

I have been trying to compile mod-perl (various 1.21 to 1.24_01 ) on Solaris
2.6 with apache (various 1.3.11 to 1.3.14) with perl-5.005003 and also
perl-5.6. If i compile it statically, i get a core dump on running apache
and if i compile it via apxs, i get a "Symbol not found main, in libperl.so"
error. I had compiled perl-5.6 using Solaris's malloc and later i compiled
perl-5.005 with perl's malloc but nothing helped. I am mostly at my wits
ends having tried all sorts of combinations. Could someone help me?

Siddhartha Jain

Re: Caching search results

[Perrin Harkins]

Bill Moseley wrote:
> Anyway, I'd like to avoid the repeated queries in mod_perl, of course.  So,
> in the sort term, I was thinking about caching search results (which is
> just a sorted list of file names) using a simple file-system db -- that is,
> (carefully) build file names out of the queries and writing them to some
> directory tree .  Then I'd use cron to purge LRU files every so often.  I
> think this approach will work fine and instead of a dbm or rdbms approach.

Always start with CPAN.  Try Tie::FileLRUCache or File::Cache for
starters. A dbm would be fine too, but more trouble to purge old entries
from.
- Perrin

[ANNOUNCE] Apache-AuthzCache 0.03

[Christian Gilmore]

The uploaded file

Apache-AuthzCache-0.03.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/C/CG/CGILMORE/Apache-AuthzCache-0.03.tar.gz
  size: 8508 bytes
   md5: 237a62049ca0cabe74fdcd62272624c1


Apache::AuthzCache is designed to work with a mod_perl
authorization module to provide caching of group membership for
site users. For a list of mod_perl authorization modules see:
 
http://www.cpan.org/modules/by-module/Apache/apache-modlist.html
 
When a request that requires authorization is received,
Apache::AuthzCache looks up the REMOTE_USER in a shared-memory
cache (using IPC::Cache) and compares the list of groups in the
cache against the groups enumerated within the "require"
configuration directive. If a match is found, the handler returns
OK and clears the downstream Authz handlers from the
stack. Otherwise, it returns DECLINED and allows the next
PerlAuthzHandler in the chain to be called.
 
After the primary authorization handler completes with an OK,
Apache::AuthzCache::manage_cache adds the new group (listed in
REMOTE_GROUP) to the cache.
 
See AuthzCache.pm pod for detailed documentation.
 
$Id: README,v 1.1 2000/09/26 20:11:50 cgilmore Exp $


2001-01-08  Christian Gilmore <[EMAIL PROTECTED]>
 
o  Better handled pre-1.26 set_handlers bugs
 
2000-09-26  Christian Gilmore <[EMAIL PROTECTED]>
 
o  Made first public release 0.02
 
$Id: ChangeLog,v 1.2 2001/01/08 17:41:17 cgilmore Exp $


Enjoy,
Christian

-
Christian Gilmore
Infrastructure & Tools Team Lead
Web & Multimedia Development
Tivoli Systems, Inc.

[ANNOUNCE] Apache-AuthzLDAP 0.51

[Christian Gilmore]

The uploaded file

Apache-AuthzLDAP-0.51.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/C/CG/CGILMORE/Apache-AuthzLDAP-0.51.tar.gz
  size: 9191 bytes
   md5: 86999685dbf96137a739e4431faa6fc9

Apache::AuthzLDAP is designed to work with mod_perl and
Net::LDAP. This module authorizes a user against an LDAP
backend. It can be combined with Apache::AuthenLDAP to provide
LDAP authentication as well.
 
See AuthzLDAP.pm pod for detailed documentation.
 
$Id: README,v 1.1 2000/09/26 18:51:51 cgilmore Exp $


2001-01-08  Christian Gilmore <[EMAIL PROTECTED]>
 
o  Fixed bug regarding nested groups whose membership was by dn
o  Better handled of pre-1.26 set_handlers bugs
 
2000-09-26  Christian Gilmore <[EMAIL PROTECTED]>
 
o  Made first public release 0.50
 
$Id: ChangeLog,v 1.2 2001/01/08 17:24:25 cgilmore Exp $


Enjoy,
Christian

-
Christian Gilmore
Infrastructure & Tools Team Lead
Web & Multimedia Development
Tivoli Systems, Inc.

[ANNOUNCE] Apache-AuthenLDAP 0.52

[Christian Gilmore]

The uploaded file

Apache-AuthenLDAP-0.52.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/C/CG/CGILMORE/Apache-AuthenLDAP-0.52.tar.gz
  size: 8013 bytes
   md5: 6a14a04f645bbec6506ad1035731e657


Apache::AuthenLDAP is designed to work with mod_perl and
Net::LDAP. This module authenticates a user against an LDAP
backend. It can be combined with Apache::AuthzLDAP to provide
LDAP authorization as well.
 
See AuthenLDAP.pm pod for detailed documentation.
 
$Id: README,v 1.1 2000/09/26 18:27:36 cgilmore Exp $


2001-01-08  Christian Gilmore <[EMAIL PROTECTED]>
 
o  Added handling of blank userid input
o  Better handled of pre-1.26 set_handlers bugs
 
2000-09-26  Christian Gilmore <[EMAIL PROTECTED]>
 
o  Made first public release 0.50
 
$Id: ChangeLog,v 1.2 2001/01/08 17:31:22 cgilmore Exp $


Enjoy,
Christian

-
Christian Gilmore
Infrastructure & Tools Team Lead
Web & Multimedia Development
Tivoli Systems, Inc.

Caching search results

[Bill Moseley]

I've got a mod_perl application that's using swish-e.  A query from swish
may return hundreds of results, but I only display them 20 at a time.  

There's currently no session control on this application, and so when the
client asks for the next page (or to jump to page number 12, for example),
I  have to run the original query again, and then extract out just the
results for the page the client wants to see.

Seems like some basic design problems there.

Anyway, I'd like to avoid the repeated queries in mod_perl, of course.  So,
in the sort term, I was thinking about caching search results (which is
just a sorted list of file names) using a simple file-system db -- that is,
(carefully) build file names out of the queries and writing them to some
directory tree .  Then I'd use cron to purge LRU files every so often.  I
think this approach will work fine and instead of a dbm or rdbms approach.


So I asking for some advice:

- Is there a better way to do this?

- There was some discussion about performance and how many files to put in
each directory in the past.  Are there some commonly accepted numbers for
this?

- For file names does it make sense to use a MD5 hash of the query string?
It would be nice to get an even distribution of files in each directory.

- Can someone offern any help with the locking issues?  I was hoping to
avoid shared locking during reading -- but maybe I'm worrying too much
about the time it takes to ask for a shared lock when reading.  I could
wait a second for the shared lock and if I don't' get it I'll run the query
again.

But it seems like if one process creates the file and begins to write
without LOCK_EX and then gets blocked, then other processes might not see
the entire file when reading.

Would it be better to avoid the locks and instead use a temp file when
creating and then do an (atomic?) rename?

Thanks very much,

Bill Moseley
mailto:[EMAIL PROTECTED]

Re: DBI

[Buddy Lee Haystack]

> Bad generic advice.  You should use persistent connections when it
> makes sense to use them.
> 
> BLH> Whether or not you use mod_perl is irrelevant.
> 
> It is relevent if you want to use Apache::DBI.


Ouch!

I was a bit more specific in my follow-up email which I sent direct since I didn't 
think it was necessary to post it to the list, but I may have been mistaken. It's 
difficult to provide detailed advice when you don't have all the information, so I did 
my best.


Subject: Re: DBI
   Date: Fri, 05 Jan 2001 17:56:53 -0500
   From: Buddy Lee Haystack <[EMAIL PROTECTED]>
 Organization: www.RentZone.org
   To: Joe Grastara <[EMAIL PROTECTED]>
   References: 1


When I first "migrated" from a Windows environment, I was absolutely amazed at how the
Unix people cobbled together independent pieces of software to solve systems 
integration
issues that plagued me in corporate americana.

A couple of issues.

When you use the Apache DBI module to maintain persistent connections to your database,
each Apache child process inherits one of the database handles, and caches the
connection. This means that your database will have to be able to have one database
connection open for each Apache child process running. If you have Apache configured to
spawn 20 child processes, the database your connecting to will have to be able to 
handle
at least the number of connections opened by just the single webserver.

I use PostgreSQL, which is compiled to handle just over 30 open connections. My website
uses 20 of those connections, which allows just over 10 other people to open up
connections to the database.

There is some undocumented command in DBI that will allow you to open a connection with
the Apache DBI module installed, but not cache the connection. I used this to connect 
to
an HR database that was rarely ever accessed.

ENJOY!!!


-- 
www.RentZone.org

RE: flushing appears to be broken with perl 5.6.0

[Sheth, Niraj]

Stas,

I am printing 4k of data for each push ..

# this to flush buffer of front end proxy-server.
my $new_line = "\n" x 4096;
print $new_line;

(make sure gzip filter if off ...)

http://forum.swarthmore.edu/epigone/modperl/kerdsnestim/14702.7611.496757.13
[EMAIL PROTECTED]


I am sure there are some other more efficient solutions which I don't know,
but would like to know.

-Niraj

-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 08, 2001 11:18 AM
To: mod_perl list
Subject: Re: flushing appears to be broken with perl 5.6.0


On Mon, 8 Jan 2001, Stas Bekman wrote:

> Hi,
>
> This simple Apache::Registry script is supposed to print the PID and then
> hang, it used to work with older mod_perl/perl versions, it doesn't print
> the PID now -- rflush doesn't seem to work. (neither $|=1 works)
>
>   my $r = shift;
>   $r->send_http_header('text/plain');
>
>   $r->print("PID = $$\n");
>   $r->rflush;
>
>   while(1){
> sleep 1;
>   }
>
> I've tested it with mod_perl-1.24_(01|02)/apache-1.3.14 and
> mod_perl-1.24/apache-1.3.12 with perl 5.6.0 (running on Linux).
>
> Has it something to do with bugs in 5.6.0? If you have the patched version
> of 5.6.0 can you please test it?

As pointed out by Niraj Sheth in the private reply I had a problem with
front-end buffering. Accessing the back-end server directly solves the
problem.

Which leads to a question, on how to make the real flush.  Currently
rflush and ($|=1) are quite useless if there is a buffering process at the
front end side.

Thanks.

_
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: flushing appears to be broken with perl 5.6.0

[Stas Bekman]

On Mon, 8 Jan 2001, Stas Bekman wrote:

> Hi,
>
> This simple Apache::Registry script is supposed to print the PID and then
> hang, it used to work with older mod_perl/perl versions, it doesn't print
> the PID now -- rflush doesn't seem to work. (neither $|=1 works)
>
>   my $r = shift;
>   $r->send_http_header('text/plain');
>
>   $r->print("PID = $$\n");
>   $r->rflush;
>
>   while(1){
> sleep 1;
>   }
>
> I've tested it with mod_perl-1.24_(01|02)/apache-1.3.14 and
> mod_perl-1.24/apache-1.3.12 with perl 5.6.0 (running on Linux).
>
> Has it something to do with bugs in 5.6.0? If you have the patched version
> of 5.6.0 can you please test it?

As pointed out by Niraj Sheth in the private reply I had a problem with
front-end buffering. Accessing the back-end server directly solves the
problem.

Which leads to a question, on how to make the real flush.  Currently
rflush and ($|=1) are quite useless if there is a buffering process at the
front end side.

Thanks.

_
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: Fwd: [speedycgi] Speedycgi scales better than mod_perl withscripts that contain un-shared memory

[Keith G. Murphy]

Les Mikesell wrote:
>
[cut] 
> 
> I don't think I understand what you mean by LRU.   When I view the
> Apache server-status with ExtendedStatus On,  it appears that
> the backend server processes recycle themselves as soon as they
> are free instead of cycling sequentially through all the available
> processes.   Did you mean to imply otherwise or are you talking
> about something else?
> 
Be careful here.  Note my message earlier in the thread about the
misleading effect of persistent connections (HTTP 1.1).

Perrin Harkins noted in another thread that it had fooled him as well as
me.

Not saying that's what you're seeing, just take it into account. 
(Quick-and-dirty test: run Netscape as the client browser; do you still
see the same thing?)

flushing appears to be broken with perl 5.6.0

[Stas Bekman]

Hi,

This simple Apache::Registry script is supposed to print the PID and then
hang, it used to work with older mod_perl/perl versions, it doesn't print
the PID now -- rflush doesn't seem to work. (neither $|=1 works)

  my $r = shift;
  $r->send_http_header('text/plain');

  $r->print("PID = $$\n");
  $r->rflush;

  while(1){
sleep 1;
  }

I've tested it with mod_perl-1.24_(01|02)/apache-1.3.14 and
mod_perl-1.24/apache-1.3.12 with perl 5.6.0 (running on Linux).

Has it something to do with bugs in 5.6.0? If you have the patched version
of 5.6.0 can you please test it?

Thanks.

_
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: DBI

[Vivek Khera]

> "BLH" == Buddy Lee Haystack <[EMAIL PROTECTED]> writes:

BLH> There are two components to DBI. The perl module is required for
BLH> database access, but the Apache DBI module is not. Although you
BLH> really should use the Apache DBI module to maintain persistent
BLH> connections to your database.

Bad generic advice.  You should use persistent connections when it
makes sense to use them.

BLH> Whether or not you use mod_perl is irrelevant.

It is relevent if you want to use Apache::DBI.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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: OT: HTML/XHTML syntax checking tools?

[Benoit Caron]

At 11:45 1/7/2001 -0600, George Sanderson wrote:
>What HTML/XHTML syntax tools are recommended?  I was hoping that the tool
>would run on the browser (client) side.  I prefer a PC version, but hey, a
>good ap is best.-)

There is a good on-line one at
http://validator.w3.org/


Check also for HTML Tidy in the link of that page : It's available for a 
great bunch of OS/Platform and it did a good job for me. Just be careful 
as, if I remember, the default option is to overwrite your original file 
and there is some things that are a bit surprising when you don't know, 
like the fact that you can't do :

 3
 
 ...


You do have to close your "" with ... which is the way it 
should be...





Benoit Caron
Analyste-Programmeur
Netgraphe - Webfin.com - Le Web Financier
[EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - -
"The number of Unix installations has grown to 10,
  with more expected."
-- The Unix Programmer's Manual, 2nd edition, June '72

Re: Strange log entry, Apache child messed up afterwards

[J. J. Horner]

* Gerd Kortemeyer ([EMAIL PROTECTED]) [010105 19:20]:
> Hi,
> 
> Did anybody ever see a message like this in the error log after an "internal
> server error"?
> 
>  [error] Undefined subroutine &Apache::lonhomework::handler called at /dev/null
> line 65535.
> 
> No further entries.
> 

Here is good, maybe:  
http://perl.apache.org/guide/debug.html#Curing_The_Internal_Server_Erro
Here is also good, maybe (the sequel): 
http://perl.apache.org/guide/debug.html#Helping_error_log_to_Help_Us
I hear this may also be good (the next generation):  
http://perl.apache.org/guide/debug.html#The_Importance_of_Warnings

If all else fails, this may be good (generations):  
http://perl.apache.org/guide/debug.html#Sometimes_My_Script_Works_Somet
I don't know, but it could help (the obligatory "We are all broke and can't handle our 
money, so we need more work"
sequel): http://perl.apache.org/guide/debug.html#Code_Debug 


If none of this helps, try Stallone, he makes more sequels.

-- 
J. J. Horner
[EMAIL PROTECTED]

Apache, Perl, mod_perl, Web security, Linux


 PGP signature

RE: Help with Limit in

[Geoffrey Young]

> -Original Message-
> From: James G Smith [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 01, 2001 1:21 PM
> To: Scott Alexander
> Cc: [EMAIL PROTECTED]
> Subject: Re: Help with Limit in  
> 
> 
> 
> Ahh...  Now we get into the interesting bits of mod_perl.  There 
> is a way to change the DocumentRoot on a per-request basis.  Just 
> not a way to do this in the config files.
> 
> Use the function Apache::document_root.  For example:
> 
> my $old_docroot = $r -> document_root($new_docroot);

hi guys... 

  I was following up on this post for the digest, did some testing, and saw
something of interest:

http://localhost/cgi-bin/foo.cgi => output of foo.cgi execution

PerlInitHandler that sets DocumentRoot to /usr/local/apache/cgi-bin
(Directory directive)
http://localhost/foo.cgi => code for foo.cgi

PerlInitHandler that sets DocumentRoot to /usr/local/apache/perl-bin
(Location directive)
http://localhost/foo.cgi => 403


interesting, uh, feature :)

--Geoff

[Take23] New articles

[Matt Sergeant]

Every now and then when I have a few new articles on take23 I hope to post
a message here. Let me know if you think I should just leave you all alone
:-)

Building Web Sites with Apache::PageKit
http://take23.org/articles/2001/01/04/pagekit.xml/1

In the first of our series of articles discussing the various options
for building web sites with mod_perl, TJ Mather talks about how
Apache::PageKit separates the development of your site into manageable
components without using embedded Perl code.

Introduction to programming in mod_perl
http://take23.org/articles/2001/01/08/intro.xml/1

Here we talk about how to go about creating your very first mod_perl
handler. This goes right to the core of how mod_perl works, for those of
you wanting to see how to program right to the metal with mod_perl, rather
than using a higher level module such as Embperl, Apache::Registry or
Mason.

Enhancing your web pages with HTML::Embperl
http://take23.org/articles/2001/01/08/embperl.xml/1

Michael Stevens introduces the reader to Embperl, an embedded HTML/Perl
module that provides many features for producing dynamic content within a
scripting environment under mod_perl. Here we find out about Embperl's
special tags for introducing code into our HTML.

As usual there's also all the news you need to stay up to date with
mod_perl. Enjoy.

Take23 - news and resources for the mod_perl world:

http://take23.org

Matt.