Manipulating @INC and tremendous blank page

--_cc79a092-a36c-4500-838e-0317a0c2676f_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit





Hi,

I've just started using ModPerl::PerlRunPrefork and mod_perl.
I've been using plain old CGI for a while in a basic MVC framework
but got the following trouble when moving to mod_perl:

- I was manipulating @INC in a BEGIN block but wasn't working.
The main app index.pl is very basic:

use strict;
use warnings;

use App::Core Run => 'App::Engine';

I was doing the manip of @INC in the App::Engine module
within a BEGIN block but then move it to the import function of App::Engine, to no unvail.
Is there a way to manipulate @INC without having to use a startup.pl in mod_perl2???

As for now, I've created a startup.pl to manipulate @INC that is called when the server is launched
but this has serveral draw backs that i would like to avoid:
- need to hardcode the path in this file (in plain old CGI relative path were ok)
- I run serveral vhosts, each of them having a cgi-bin, each of them containing several projects
with their particular setups, ie:

domain1.com/cgi-bin/project1/conf/config
domain1.com/cgi-bin/project2/conf/config
domain2.com/cgi-bin/project1/conf/config
....

How can I load the proper startup.pl on a per vhost, folder basis and assuring
that project2 conf in domain1.com is not going to be project1 conf or even domain2.com project2 conf?

I really do not like to have to hardcode so manythings in so many places, especially because i've been
using this framework in many different confs and the hassle to maintain this is not good (compare to huh, mod_php?)

I've tried also ModPerl::RegistryPrefork but got some tremendous blank pages that leaved no log at all.
When I was browsing the app it was ok for few clicks but if i speed the clicked space, got just blank page
with content-length 0, 200 ok status and well, 15ms response time, like if the App::Engine wasn't even loaded.
I have absolutely no clue on how to debug this ??

I am sorry for this long mail (i've searched for the blank page problem but got no archives close to what i have).

Thank you

____________________________________________________________ _____
MSN相談党、誕生。あなたの知識で日本を変えよう。党首には押切もえが就任！
http://clk.atdmt.com/GBL/go/msnjpqja0010000017gbl/direct/01/
--_cc79a092-a36c-4500-838e-0317a0c2676f_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit









Hi,

I've just started using ModPerl::PerlRunPrefork and mod_perl.
I've been using plain old CGI for a while in a basic MVC framework
but got the following trouble when moving to mod_perl:

- I was manipulating @INC in a BEGIN block but wasn't working.
The main app index.pl is very basic:

use strict;
use warnings;

use App::Core Run => 'App::Engine';

I was doing the manip of @INC in the App::Engine module
within a BEGIN block but then move it to the import function of App::Engine, to no unvail.
Is there a way to manipulate @INC without having to use a startup.pl in mod_perl2???

As for now, I've created a startup.pl to manipulate @INC that is called when the server is launched
but this has serveral draw backs that i would like t
o avoid:
- need to hardcode the path in this file (in plain old CGI relative path were ok)
- I run serveral vhosts, each of them having a cgi-bin, each of them containing several proje
cts
with their particular setups, ie:

domain1.com/cgi-bin/project1/conf/config
domain1.com/cgi-bin/project2/conf/config
domain2.com/cgi-bin/project1/conf/config
...

How can I load the proper startup.pl on a per vhost, folder basis and assuring
that project2 conf in domain1.com is not going to be project1 conf or even domain2.com project2 conf?

I really do not like to have to hardcode so manythings in so many places, especially because i've been
using this framework in many different confs and the hassle to maintain this is not good (compare to huh, mod_php?)

I've tried also ModPerl::RegistryPrefork but got some tremendous blank pages that leaved no log at all.
When I was browsing the app it was ok for few clicks but if i speed the clicked s
pace, got just blank page
with content-length 0, 200 ok status and well, 15ms response time, like if the App::Engine wasn't even loaded.
I have absolutely no clue on how to debug this
??

I am sorry for this long mail (i've searched for the blank page problem but got no archives close to what i have).

Thank you


--_cc79a092-a36c-4500-838e-0317a0c2676f_--

Re: Manipulating @INC and tremendous blank page

On Fri, 13 Feb 2009, shiriru0111@hotmail.com wrote:
> - I was manipulating @INC in a BEGIN block but wasn't working.
> The main app index.pl is very basic:
>
> use strict;
> use warnings;
>
> use App::Core Run => 'App::Engine';
>
> I was doing the manip of @INC in the App::Engine module
> within a BEGIN block but then move it to the import function of App::Engine, to
> no unvail.

Would this work in your CGI instead of fiddling with @INC:

use FindBin;
use lib "$FindBin::Bin/../lib";

or something like that?

Mark

Re: Manipulating @INC and tremendous blank page

On Thu, Feb 12, 2009 at 9:55 PM, wrote:
> Is there a way to manipulate @INC without having to use a startup.pl in
> mod_perl2???

Sure. For example, PERL5LIB.

> As for now, I've created a startup.pl to manipulate @INC that is called when
> the server is launched
> but this has serveral draw backs that i would like to avoid:
> - need to hardcode the path in this file (in plain old CGI relative path
> were ok)

Regarding relative paths, I wouldn't recommend putting your perl
libraries inside of DOCUMENT_ROOT if you can avoid it.

If you have to use relative paths, you want something like what Mark
Hedges suggested. That should work for ModPerl::PerlRun, where your
code is compiled every time. For ModPerl::Registry, you'd need to do
something like this:

use FindBin;
unshift @INC, "$FindBin::Bin/../lib";

Unlike "use lib", the unshift will run every time in Registry. Also,
if you use RegistryPrefork you won't need FindBin at all. You can
just use '../lib'.

> I've tried also ModPerl::RegistryPrefork but got some tremendous blank pages
> that leaved no log at all.
[...]
> I have absolutely no clue on how to debug this ??

There are a few things I would try:
- Double-check the log file
- Add some warn statements to see how far it gets.
- Examine the communication with the client through a proxy or Firefox plugin.

I think that ModPerl::RegistryPrefork is ultimately where you want to
be, because it will be faster.

- Perrin

RE: Manipulating @INC and tremendous blank page

--_f9348f80-24d5-4201-ab35-14fff4d55f9c_
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit


Thank you, Mark & Perrin for your help!
> > Is there a way to manipulate @INC without having to use a startup.pl in> Sure. For example, PERL5LIB.

Yes, sure. Sorry,my question wasn't correctly formulated.
Below is closer to what I was looking for and should have expressed.
> Regarding relative paths, I wouldn't recommend putting your perl> libraries inside of DOCUMENT_ROOT if you can avoid it.

In fact, in our staging environment libraries are working copies from subversion,
hosted one folder above the domain folders with all the vhosts
and we use symlink that point to them in the cgi-bin.
it's perhaps a strange way of doing things (and if there's better, i'll take!!)
but we want to assume the most hostile environment
possible where we cannot do what we want, with the server and with perl (as it does happen with some clients).
so in case of a contrived,restricted environment, we can just plug the entire framework and have it works.
If we can change things for our best and the best of our client, we will accomodate accordingly.
this is a compromise between SA/maintainability/flexibility and hassle^^;


> If you have to use relative paths, you want something like what Mark> Hedges suggested. That should work for ModPerl::PerlRun, where your> code is compiled every time. For ModPerl::Registry, you'd need to do> something like this:> > use FindBin;> unshift @INC, "$FindBin::Bin/../lib";> > Unlike "use lib", the unshift will run every time in Registry. Also,> if you use RegistryPrefork you won't need FindBin at all. You can> just use '../lib'.

I am using FindBin and added the FindBin::again() as recommanded
in hope to switch to ModPerl::RegistryPrefork soon.
I am using both use lib and unshift @INC but still, for some reasons,
even with ModPerl::PerlRunPrefork got some pages that could not load
and in the log, it was always due to a lib that couldn't be found.
If I reload the page, it works, If I reload again sometimes it won't.
Adding the startup.pl, get rid of this behavior.
But I will change all use lib into unshift @INC and see how it behaves.
I have to say that I do not really understand how mod_perl behaves regarding the @INC manipulation.

> > I've tried also ModPerl::RegistryPrefork but got some tremendous blank pages> > that leaved no log at all.> > I have absolutely no clue on how to debug this ??> - Double-check the log file
Nothing there.> - Add some warn statements to see how far it gets.
I was putting print statement, but you're right should switch to warn!!
as for the print statements, it seems that the index.pl print statements were executed
but none of the print statements in the loaded module. so I assumed that the module wasn't loaded
but do not understand sometimes it is, sometimes it is not.
> - Examine the communication with the client through a proxy or Firefox plugin.

I've checked it thru firebug but is there a better plugin?
> I think that ModPerl::RegistryPrefork is ultimately where you want to> be, because it will be faster.

indeed!!!
I guess i will have to deal with some circular references lurking here and there, sloppy old code
needing rewrites,etc
but this should boost the app so I definitely aim at switching to ModPerl::RegistryPrefork!

I have to say that switching to ModPerl::PerlRunPrefork allowed me to improve the performance in a amasing way!
Well, i have checked the performance with Apache Benchmark (ab n 100 c 5,etc)
and got a boost of about 20 times the cgi version when the simulated traffic is high!!
Still, the ratio is very low but that is a real improvement and am really looking forward to it!
(this is true for pages that were cached with Cache::Cache but required perl to be executed in some way)


Thank you very much for your fast reply !



____________________________________________________________ _____
5GBのオンラインファイル保存サービス。Hotmailでファイル共有もできる！
http://clk.atdmt.com/GBL/go/msnjpqjl0090000077gbl/direct/01/
--_f9348f80-24d5-4201-ab35-14fff4d55f9c_
Content-Type: text/html; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit






Thank you, Mark & Perrin for your help!


> > Is there a way to manipulate @INC without having to use a startup.pl in
> Sure. For example, PERL5LIB.

 

Yes, sure. Sorry,my question wasn't correctly formulated.

Below is closer to what I was looking for and should have expressed.


> Regarding relative paths, I wouldn't recommend putting your perl
> libraries inside of DOCUMENT_ROOT if you can avoid it.

 

In fact, in our staging environment libraries are working copies from subversion,

hosted one folder above the domain folders with all the vhosts

and we use symlink that point to them in the cgi-bin.

it's perhaps a strange way of doing things (and if there's better, i'll take!!)

 but we want to assume the most hostile environment

possible where we cannot do what we want, with the server and with perl (as it does happen with some clients).

so in case of a contrived,restricted environment, we can just plug the entire framework and have it works.

If we can change things for our best and the best of our client, we will accomodate accordingly.

this is a compromise between SA/maintainability/flexibility and hassle^^;

 

 


> If you have to use relative paths, you want something like what Mark
> Hedges suggested. That should work for ModPerl::PerlRun, where your
> code is compiled every time. For ModPerl::Registry, you'd need to do
> something like this:
>
> use FindBin;
> unshift @INC, "$FindBin::Bin/../lib";
>
> Unlike "use lib", the unshift will run every time in Registry. Also,
> if you use RegistryPrefork you won't need FindBin at all. You can
> just use '../lib'.

 

I am using FindBin and added the FindBin::again() as recommanded

in hope to switch to ModPerl::RegistryPrefork soon.

I am using both use lib and unshift @INC but still, for some reasons,

even with ModPerl::PerlRunPrefork got some pages that could not load

and in the log, it was always due to a lib that couldn't be found.

If I reload the page, it works, If I reload again sometimes it won't.

Adding the startup.pl, get rid of this behavior.

But I will change all use lib into unshift @INC and see how it behaves.

I have to say that I do not really understand how mod_perl behaves regarding the @INC manipulation.

 


> > I've tried also ModPerl::RegistryPrefork but got some tremendous blank pages
> > that leaved no log at all.
> > I have absolutely no clue on how to debug this ??

> - Double-check the log file

Nothing there.
> - Add some warn statements to see how far it gets.

I was putting print statement, but you're right should switch to warn!!

as for the print statements, it seems that the index.pl print statements were executed

but none of the print statements in the loaded module. so I assumed that the module wasn't loaded

but do not understand sometimes it is, sometimes it is not.


> - Examine the communication with the client through a proxy or Firefox plugin.

 

I've checked it thru firebug but is there a better plugin?

 
> I think that ModPerl::RegistryPrefork is ultimately where you want to
> be, because it will be faster.

 

indeed!!!

I guess i will have to deal with some circular references lurking here and there, sloppy old code

needing rewrites,etc

but this should boost the app so I definitely aim at switching to ModPerl::RegistryPrefork!

 

I have to say that switching to ModPerl::PerlRunPrefork allowed me to improve the performance in a amasing way!

Well, i have checked the performance with Apache Benchmark (ab n 100 c 5,etc)

and got a boost of about 20 times the cgi version when the simulated traffic is high!!

Still, the ratio is very low but that is a real improvement and am really looking forward to it!

(this is true for pages that were cached with Cache::Cache but required perl to be executed in some way)

 

 

Thank you very much for your fast reply !

 

 


 

Re: Manipulating @INC and tremendous blank page

On Fri, Feb 13, 2009 at 11:30 PM, wrote:
> I am using FindBin and added the FindBin::again() as recommanded
> in hope to switch to ModPerl::RegistryPrefork soon.
> I am using both use lib and unshift @INC but still, for some reasons,
> even with ModPerl::PerlRunPrefork got some pages that could not load
> and in the log, it was always due to a lib that couldn't be found.
> If I reload the page, it works, If I reload again sometimes it won't.
> Adding the startup.pl, get rid of this behavior.
> But I will change all use lib into unshift @INC and see how it behaves.
> I have to say that I do not really understand how mod_perl behaves regarding
> the @INC manipulation.

IIRC, the deal is that if you change @INC before the server forks it
will get picked up by all child processes and stay, but if you change
it after the fork it will be reset after the end of the request. The
problem with "use lib" is that it only run once, at compile-time. In
Registry, your code gets compiled on the first request, and afterward
it just executes the compiled code, so @INC gets reset but "use lib"
doesn't run again. The "unshift @INC" will run every time.

> I've checked it thru firebug but is there a better plugin?

I normally use a proxy for this, so I'm not sure. It doesn't matter
what you use, as long as it lets you see the full HTTP communication
back and forth.

> I have to say that switching to ModPerl::PerlRunPrefork allowed me to
> improve the performance in a amasing way!
> Well, i have checked the performance with Apache Benchmark (ab n 100 c
> 5,etc)
> and got a boost of about 20 times the cgi version when the simulated traffic
> is high!!

That's a great start.

> (this is true for pages that were cached with Cache::Cache but required perl
> to be executed in some way)

Have you looked at CHI, the new replacement for Cache::Cache? It has
faster storage options.

- Perrin