Re: Newbie help with Apache2::Request configuration

-------- Original Message  --------
From: "Philip M. Gollucci" <pgollucci <at> p6m7g8.com>
To: Jonathan Vanasco <jon <at> 2xlp.com>
Cc: mod_perl List <modperl <at> perl.apache.org>
Subject: Re:Newbie help with Apache2::Request configuration
Date: Sat Dec 31 2005 19:22:28

> Jonathan Vanasco wrote:
>>
>> On Dec 31, 2005, at 1:22 PM, Philip M. Gollucci wrote:
>>
>>> One does CGI compatible decoding the other doesn't.
>>
>> fully knowing this sounds stupid, can i just ask what that means?
> APR::Request provides 2 functions encode and decode that access 
> application/x-www-form-urlencoded data
> which the Apache2::Cookie methods freeze and thaw call for you internally.
> 
> APR::Request::Cookie 's freeze/thaw are "no ops" per say... just data 
> in/out.
> 

--snip--

Philip,

My apologies for being a dumbo, your forbearance is much appreciated!

You seem to recommend the APR:* interfaces, but then go on to show that 
to use APR::Request::Param to handle uploads, we will have to code 

Re: Newbie help with Apache2::Request configuration

> My apologies for being a dumbo, your forbearance is much appreciated!
no problem... Everybody has to start somewhere.

> 
> You seem to recommend the APR:* interfaces, but then go on to show that 
> to use APR::Request::Param to handle uploads, we will have to code 
> wrapper code similar to that in Apache2::Upload each time, for ourselves?
I was really just trying to illustrate a use of it and show that the 
Apache2::* API's are wrappers or applications of the APR.  Thus, you can 
do anything with the APR::* methods you could with the Apache2:: ones.

> I also didn't understand the difference between the two cookie classes, 
> except that there is an implication that the APR::Request::Cookie 
> classes do not call freeze/thaw automatically? Does this mean that I 
> have to call encode/decode on values when I create or access 
> APR::Request::Cookie cookies?
One does encoding decoding for you aka ' ' => %20
You might not need this depending on what you put in your cookies.
APR's Cookies does call them, but there are not the same freeze thaw.
There implemented as:
sub freeze { };
sub thaw { shift->value }
[Thats from memory so don't quote me on it]

Whereas Apache2's Cookie are more complex.

> I can't even seem to get the APR::Request->new() to work. 
> [embarrassment!] Mmmm, maybe there isn't a new() method? Or maybe my 
> install is broken: Can't locate auto/APR/Request/new.al
sub handler {

Re: Newbie help with Apache2::Request configuration

-------- Original Message  --------
From: "Philip M. Gollucci" <pgollucci <at> p6m7g8.com>
To: Jeff Armstrong <modperl <at> aquabolt.com>
Cc: mod_perl List <modperl <at> perl.apache.org>
Subject: Re:Newbie help with Apache2::Request configuration
Date: Sun Jan 01 2006 21:01:39

>> My apologies for being a dumbo, your forbearance is much appreciated!
> no problem... Everybody has to start somewhere.
> 

Thanks for all that - I will work through it!

Regards
Jeff

Re: Strange test results

On Fri, 2005-12-30 at 16:57 -1000, Beau E. Cox wrote:
> 3) Configuration:
> 
> Apache 2.3 (svn trunk):

I think that's the issue.  Apache 2.3 is not working yet, AFAIK,
although you could try the latest mod_perl from svn.

- Perrin

Re: Adding customs httpd.conf data in mod_perl 2.0

On Fri, 2005-12-30 at 11:30 -0800, Curtis Poe wrote:
> We're hoping to avoid bundling Apache2 because that would contradict 
> the design goal.  Specifically, if someone has an existing mod_perl 1, 
> mod_perl 2, FastCGI or other server, we'd like things to, as much as 
> possible, "play nicely" with them.

You probably are aware of this, but the difficulty with that approach is
that many people run really bizarre apache/mod_perl installs.  They
compile in flaky modules, or mis-configure things so that your conf
additions don't work, or run out-of-date versions with known problems.
Trying to cooperate with all of that will put you in the position of
remotely troubleshooting every user's local apache problems.

> Bundling a bunch of stuff they 
> don't need would be disastrous.

The apache source is pretty small by modern standards, and easy to
relocate to a special location where it can be removed simply.

> Trying to maintain separate bundles 
> for every configuration option and OS would also be very difficult.  
> (different platforms, servers and data stores)

Apache/mod_perl builds with the included scripts with no intervention on
most platforms.

What you're trying to do (add some stuff to the config) should be no
problem, but if you run into many issues with people's local builds of
apache, I think you may want to reconsider bundling it and building a
sane binary during your install.  You could always offer both options,

Why is my apache parent process growing...

Re: Why is my apache parent process growing...

On Mon, 2 Jan 2006 20:34:42 +0100
"Len Kranendonk" <len <at> primaat.com> wrote:

> Happy 2006 everyone,
> 
> I'm running Apache/2.0.54, mod_perl/2.0.1, Perl/v5.8.7 on FreeBSD
> 6.0. 
> 
> Right after starting apache (with preloading the needed perl modules)
> the httpd root process is about 40MB. After several days it has grown
> to over 100MB.
> 
> I'm using Apache2::SizeLimit to kill of httpd childs that get too
> large. I'm using this configuration:
> 
> $Apache2::SizeLimit::MAX_PROCESS_SIZE = 100000;
> $Apache2::SizeLimit::MAX_UNSHARED_SIZE = 25000;
> 
> The problem here is that when the Apache parent process gets 100000
> KB big, the spawned childs also are that size, which means that a
> spawned child is killed immediately after it served its first
> request. The only way to decrease the parent size is to stop and
> start apache.
> 
> My understanding is that the parent process is not supposed to serve
> any requests itself. It's entire job is to manage the children. So,
> how come it is growing, and more importantly, how can I control it ?
> 
> BTW: I have this problem on all our FreeBSD boxes running different
> applications. Is FreeBSD / mod_perl just a bad combo ?

  No there shouldn't be any issues with mod_perl on FreeBSD that
  would cause this... this is more than likely an issue with your code. 

  Do you have any globals or other shared information that grows very
  large?  Do you read in any large data sets either from a database or
  a file into the application all at once? 

 ---------------------------------
   Frank Wiles <frank <at> wiles.org>
   http://www.wiles.org
 ---------------------------------

Re: Why is my apache parent process growing...

On Mon, 2006-01-02 at 20:34 +0100, Len Kranendonk wrote:
> Right after starting apache (with preloading the needed perl modules)
> the httpd root process is about 40MB. 
> After several days it has grown to over 100MB.

How are you measuring this?

> My understanding is that the parent process is not supposed to serve
> any requests itself.

That's correct.  Are you using Cache::FastMmap, or anything else that
does memory-mapping of files?  That might yield an apparent larger size
if the parent process is one of the ones that has the mmap'ed file open.

- Perrin

Re: Why is my apache parent process growing...

>  Do you have any globals or other shared information that grows very
>  large?  Do you read in any large data sets either from a database or
>  a file into the application all at once?

We're using a global %session hash, which is undef 'fed when the session is 
closed.
I'm not reading in large data sets, but even if I did that should grow the 
child process,
not the parent process, right ?

The application I'm talking about is WebGUI, a CMS written in perl. I've 
mailed the
WebGUI list earlier today. It seems that the people running on Linux don't 
have the
problem that's causing me pain. That's why I start to believe that it's a 
FreeBSD/mod_perl issue.

The problem is not limited to WebGUI, I also have it on two boxes that serve 
football
results. The only thing that's running there is SOAP::Lite, HTML::Template, 
XML::Simple
and Cache::FileCache. After two months that http root process has grown from 
20MB to 185MB.

Len

Re: Why is my apache parent process growing...

On Mon, 2006-01-02 at 21:48 +0100, Len Kranendonk wrote:
> We're using a global %session hash, which is undef 'fed when the session is 
> closed.
> I'm not reading in large data sets, but even if I did that should grow the 
> child process,
> not the parent process, right ?

Right.

> The application I'm talking about is WebGUI, a CMS written in perl. I've 
> mailed the
> WebGUI list earlier today. It seems that the people running on Linux don't 
> have the
> problem that's causing me pain. That's why I start to believe that it's a 
> FreeBSD/mod_perl issue.

It may be a problem with the way FreeBSD reports memory usage rather
than true growth of the parent process.

> The problem is not limited to WebGUI, I also have it on two boxes that serve 
> football
> results. The only thing that's running there is SOAP::Lite, HTML::Template, 
> XML::Simple
> and Cache::FileCache.

Are you using IPC::SharedCache for your HTML::Template caching?

- Perrin