Turning PerlFreshRestart Off breaks app

2008-12-16 Thread Mike Glen
I am currently trying to migrate an old web app from perl 5.6.2 to perl 
5.8.8

One of the reasons for this is so I can use Moose.
I discovered that I couldnt preload Moose classes when PerlFreshRestart 
was set to On


Unfortuantely after turning this to off, I can preload Moose classes in 
my startup.pl without any problems
but in the old app code I start to get errors about not being able to 
load methods

eg Can't locate object method new via package App::UserManager

The package App::UserManager does have a new method and it all runs ok 
with PerlFreshRestart On

All the old app modules are preloaded in startup.pl

If I turn PerlFreshRestart Off using perl 5.6.2 this problem does not occur.

can anyone give me any suggestions what I should look at to try and fix 
this problem


Server version: Apache/1.3.37 (Unix)
Running on Centos
Apache/mod_perl/perl were all built from source

Thanks
Mike

--
MINDsweep
25 albany street
edinburgh - UK - eh1 3qn

m: 07786984428


MINDsweep www.mindsweep.net is a division of c2sky services limited
www.c2sky.net

This e-mail may contain confidential information.  It is intended solely
for the attention of the designated recipient(s).  If you are not the
intended recipient, you must not make any use of the information
contained in the e-mail or cause or allow anyone to do so.  Please
contact the sender immediately and delete the message. 





Re: which reverse proxy for modperl?

2008-12-16 Thread Frank Wiles
On Sat, 13 Dec 2008 03:02:00 +0100 (CET)
Jeff Pang pa...@laposte.net wrote:

 Hello,
 
 I have a modperl application on a host which is running with heavy
 load. I have the plan to put a reverse proxy before it.
 There are two well known reverse proxy software, one is Squid,
 another is nginx. Which one is better for modperl application? or is
 there any others which are better than these two?

I've used mod_proxy, Perlbal, and nginx.  These days nginx is my
favorite, it just works and has a ton of features. Also it appears to
have the most active community development, but that's subjective as I
don't follow them all very closely. 

 ---
   Frank Wiles, Revolution Systems, LLC. 
 Personal : fr...@wiles.org  http://www.wiles.org
 Work : fr...@revsys.com http://www.revsys.com 



Re: mod_perl vs. mod_python

2008-12-16 Thread Frank Wiles
On Sat, 13 Dec 2008 12:58:36 +0100 (CET)
Jeff Pang pa...@laposte.net wrote:

 Just ask out of being curious, are mod_perl and mod_python the same
 or similar stuff? Which is better (in performance or ease to use)?

They are basically the same thing.  A language specific binding to the
Apache API.  One with Perl the other with Python.  I've not seen any
performance benchmarks comparing them, but I would imagine they are
very similar in terms of performance. 

 ---
   Frank Wiles, Revolution Systems, LLC. 
 Personal : fr...@wiles.org  http://www.wiles.org
 Work : fr...@revsys.com http://www.revsys.com 



Re: perl rpm for CentOS/RHEL 5 available or advice

2008-12-16 Thread Fred Moyer
On Mon, Dec 15, 2008 at 9:48 AM, Kurt Hansen khan...@charityweb.net wrote:
 Hello,

 I've rolled my own perl, mod_perl, and Apache from source so far but plan to
 use rpms going forward to make it easier to setup and maintain multiple
 machines.

 As I understand rpms, I can either use the stock rpms from CentOS or create
 my own by getting the src.rpm, modifying the spec file, and then using
 rpmbuild to create a new rpm. I'm not clear on the details on this, but I'm
 sure I can figure it out using the documentation at rpm.org.

 While the stock rpms from CentOS may be fine for Apache and mod_perl, the
 stock perl is not optimal for running mod_perl since, for one, it has
 threading turned on. (As I understand from reading this list.) Thus, for
 perl I will have to create my own rpm.

 Has anyone done this for CentOS/RHEL 5? I've searched for an perl rpm
 without threading but haven't found one for CentOS. Any pitfalls I should be
 aware of?

I have taken on this dragon of building a perl rpm.  I was able to
successfully make it happen, but I have some advice for you.  Good
luck, and don't give up :)

Rolling a perl rpm is harder than it looks (at least the one I did).
I was creating a 5.8.8 rpm on 5.6.1 system perl, so maybe that made it
extra difficult.

You'll want to make this rpm install perl in a location other than
/usr/bin/perl - that adds more difficulty.  Remember, you can't remove
the system perl because lots of other rpms depend upon it.

I'd suggest taking a SPEC file from the source rpms for your
distribution and start there.  Start with trying to rebuild the
existing rpm for your system perl which is threaded, just to get
comfortable with the process.  Then try introducing your own source
and changing the install location (that's where it really gets tricky,
but it isn't impossible).  You won't need all the patch files which
come with the Centos/RHEL rpm.

 I'm planning to still use CPAN to install most perl modules once perl is
 installed.

Once you get the perl rpm rolled, I'd recommend looking at Ovid (the
package) on CPAN; it makes perl module rpms fairly painless.


content_type in SSI- or directly-called mp2 scripts

2008-12-16 Thread craig

My mod_perl2 scripts mostly fall into 2 categories:

1) scripts that are called by URL location, and generate complete  
content-pages
2) scripts that are called by SSI include virtual sequences  
in .html files, and generate part of a page


In some cases scripts of type 1 directly call scripts of type 2 to  
generate parts of their pages.

(Call this case 3).

My questions are about when to call $r-content_type('text/html')

Such a call is a good idea in category 1, right?

Such a call probably should not be made by the directly-called script  
in case 3, right?
Apache probably can't even tell that a new script has gotten into the  
act, the calling
and called script are both in the undifferentiated sea of mod-perl  
code, right?


In an SSI-invoked script (category 2) is a content_type call a)  
required, b) good practice,

or c) a bad idea?

Thanks,
cmac
www.animalhead.com