headers
Christian Hoermann | 1 Jul 2007 06:12
Picon

Re: 200 Response on die

Hello Clint,

> Yes, it is intended behaviour.

thank you for clarifying this.

> What I do is keep all of my content in a single variable, and once
> pretty much everything that could die has finished, I
> $r->print($content) as the last action by my handler.

> All the previous code is wrapped in an eval, so I can catch any die's
> and send a custom error page instead of $content.

That sounds like a really good way to do it; I was thinking of doing
it like that too. Combining this with a good exception handling module
will allow for some helpful and more specific error pages.

> Also, have a read of these docs:
> http://perl.apache.org/docs/2.0/user/coding/coding.html#Integration_with_Apache_Issues

Thanks for the link, I've had a read of it and most of the other
documentation on the site. It's good that there's quite a bit of
detailed documentation for mod_perl.

Best Regards,

Christian
Permalink | Reply | 0 comments |
headers
Tony van der Hoff | 1 Jul 2007 10:47

Re: Problems using Apache::Reload

On 30 Jun at 16:55 Jonathan Vanasco <jvanasco <at> 2xlp.com> wrote in message
<03AE2161-DD72-4E32-B2DE-55CC9D025718 <at> 2xlp.com>

[snip]
> assuming you're on a nix/bsd -- you need to be able to restart the server.
> if you can't , then you shouldn't be using mod_perl. 
[snip]

Thank you, Jonathan, for your more detailed explanation. I have to say, I am
extremely disappointed with my experience. I've used PHP for some years to
create interactive web sites with some success, but having read about the
significant performance boost available from mod_perl, I bit the bullet, and
used PERL for the first time on my current project. Had I known then what I
know now, I wouldn't have bothered :-( 

I don't even like the language much, but I'm sure that's a personal thing.

It looks then like I have two options:
1. abandon mod-perl and just use cgi. 
2. move the project to a server over which I have full control.

(1) rather defeats the object of using PERL, and I am loth to acknowledge
defeat; (2) adds significant expense, and extra effort, to the project. Bah
- what a mess!

Thanks again, Tony

--

-- 
Tony van der Hoff        | mailto:tony <at> vanderhoff.org
Buckinghamshire, England
(Continue reading)

Permalink | Reply | 2 comments |
headers
Clinton Gormley | 1 Jul 2007 11:26
Gravatar

Re: Problems using Apache::Reload

Tony - There are lots of people using Registry successfully (in fact the
new Bugzilla uses Registry, if I remember correctly).

> Thank you, Jonathan, for your more detailed explanation. I have to say, I am
> extremely disappointed with my experience. I've used PHP for some years to
> create interactive web sites with some success, but having read about the
> significant performance boost available from mod_perl, I bit the bullet, and
> used PERL for the first time on my current project. Had I known then what I
> know now, I wouldn't have bothered :-( 
> 
> I don't even like the language much, but I'm sure that's a personal thing.

Give it time. I'm maintaining some PHP code, and all I want to do is
rewrite it in Perl.

> 
> It looks then like I have two options:
> 1. abandon mod-perl and just use cgi. 
> 2. move the project to a server over which I have full control.
> 
> (1) rather defeats the object of using PERL, and I am loth to acknowledge
> defeat; (2) adds significant expense, and extra effort, to the project. Bah
> - what a mess!

I think that Jonathan is exaggerating the risks, and if you don't have
the luxury of running your own server then it is quite acceptable to use
these modules. See here for some points about the trade-offs that you
make :
http://search.cpan.org/~pgollucci/mod_perl-2.0.3/docs/api/Apache2/Reload.pod#Performance_Issues
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tony van der Hoff | 1 Jul 2007 12:06

Re: Problems using Apache::Reload

On 30 Jun at 11:13 Clinton Gormley <clint <at> traveljury.com > wrote in message
<1183198421.4692.29.camel <at> getafix.traveljury.com>

Thanks, Clint, for your helpful reply.

> Disclaimer: I have never used Apache::Reload, but:
> 
> Apache::Registry already looks for changes to your scripts and reloads
> them as necessary. So you shouldn't need to use both of them.  

Well, I agree it says that, but when I tried using Registry without Reload,
it didn't seem to work, so I gave up, and used Reload, more-or-less
successfully.

[snip]
> 
> Secondly, the problem of it not finding your modules - you need to add a :
> use lib '/path/to/my/modules'; somewhere early on, for instance in a
> startup.pl file that is included in your config, or in one of the first
> lines of your .pl files.
> 
Yeah, well, startup.pl is out of the question if the httpd.conf is
unavailable, and the server can't be restarted. 

My understanding is that adding the "use lib" line is certainly required,
but only takes effect on invocation of the .pl code. If the modules are
already cached, then they are not reloaded. So that's where Apache::Reload
comes in. Any registered modules are stat'ed, and reloaded as necessary
*before* the .pl code are executed, and therefore *before* any "use lib"
instructions are processed.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Clinton Gormley | 1 Jul 2007 12:29
Gravatar

Re: Problems using Apache::Reload


> > 
> > Apache::Registry already looks for changes to your scripts and
> reloads
> > them as necessary. So you shouldn't need to use both of them.  
> 
> Well, I agree it says that, but when I tried using Registry without
> Reload,
> it didn't seem to work, so I gave up, and used Reload, more-or-less
> successfully.
> 

Registry checks whether your script has changed:
 - eg cgi-bin/login.pl

But if login.pl contains 'use My::Module', it doesn't check for that
module, which is why you would need Apache::Reload as well.

> So, I would, for instance, have a .pl file which contains
> ...
> use lib ".";	# I believe this is implicit, anyway.
> use CCC::MyDBI;
> ...

This is one of the gotchas I mentioned before: CHDIR.

You can't rely on it.  Something somewhere (maybe Registry itself) is
changing the current dir, so '.' now refers to / rather than
to /path/to/your/modules.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Perrin Harkins | 1 Jul 2007 16:26

Re: Problems using Apache::Reload

On 7/1/07, Clinton Gormley <clint <at> traveljury.com> wrote:
> This is one of the gotchas I mentioned before: CHDIR.
>
> You can't rely on it.  Something somewhere (maybe Registry itself) is
> changing the current dir, so '.' now refers to / rather than
> to /path/to/your/modules.

It's actually not that something is doing a chdir, but that Registry
is NOT doing one.  In a CGI environment, the current directory is
always set to the directory where the script lives.  Unfortunately,
this is not safe for a threaded environment, so Registry doesn't do it
by default.

A subclass of Registry that deals with this is included in the
mod_perl distribution.  It's called ModPerl::RegistryPrefork.  There's
more explanation here:
http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Registry___C_Apache__PerlRun__and_Friends

- Perrin
Permalink | Reply | 0 comments |
headers
CraigT | 1 Jul 2007 21:06
Picon
Favicon

passing CGI paramters


Hello,

I'm trying to bring my application up using ModPerl::PerlRun.  I have
anchors at places in my code like <A CLASS='l2'
HREF='vumenu.cgi?str=$govlevel~$vufiles'  where I'm passing parameters to
the HREF.   It works under CGI, but when I try this under PerRun only the
parameters before the ~ come accross.   I've tried other separators that
work under CGI with the same effect under PerlRun.

Any guidance will be appreciated.   Thanks.

Respectfully,
CraigT 
--

-- 
View this message in context: http://www.nabble.com/passing-CGI-paramters-tf4008753.html#a11384626
Sent from the mod_perl - General mailing list archive at Nabble.com.
Permalink | Reply | 3 comments |
headers
Marcus J Coles | 1 Jul 2007 22:01
Picon

Re: Problems using Apache::Reload


> Re a virtual server solution - I've been looking for one as well. Here
> are a few I've found (haven't tried them yet):
>
> http://order.1and1.co.uk/xml/order/VpsRoot?__frame=_top&__lf=Static
> http://www.spry.com/plesk-vps/
> http://www.vpslink.com/
>   
fwiw : Since your based in the UK give these guys a try:

http://www.memset.com

I run a few m_p apps on their vps' and they are cheap enough to let you 
dip your toe in the water
+ given that they haven't been bought out yet they still have that rare 
commodity :
support by the same people that run the show

Marcus

PS I don't work for them !-)
Permalink | Reply | 0 comments |
headers
Jonathan Vanasco | 1 Jul 2007 22:43

Re: Problems using Apache::Reload


You're comparing Apples to Rocks with php & mod_perl ( rocks was the  
first non-fruit thing I could think of )

php has 3 main flavors - mod_php , php-cgi , php-cli

lets just look at mod_php and php-cgi

	if you run perl and php through a fastcgi proxy , you're going to  
get similar performance from an architecture standpoint.  each  
language will be a bit faster or slower depending on its strengh or  
weakness in whatever you test, but the overall design of the systems  
will be the same, and you won't see much of a difference.

	mod_php and mod_perl sound kind of similar..

		mod_php is sticking a php interpreter in apache , and using that to  
process files
		mod_perl is sticking a perl interpreter in apache , and using that  
to process files ( it can script apache + integrate with hooks too )

	but they behave a little differently because of the way they have  
very different approaches in the way they handle memory - shared  
memory, loading libraries, copy on write, etc
	they also have slightly different architectures

most people use mod_perl in dedicated environments -- it achieves its  
speed performance by compiling & caching code -- which eats up  
memory.  because code is handled with the package namespaces, people  
generally don't run it in shared environments, as you provide
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jens Helweg | 2 Jul 2007 14:38
Picon
Picon

Re: Where is Perl compilation output when using modperl ?

Hello everyone,

To sum this up: I had no luck in my efforts to get the perl compilation 
output to show up somewhere (on win32). I have tried several (basic) 
thinks. I have put it aside for now and will switch to linux as I do not 
have the time to spend more hours on researching this.
Thanks for everyone's help !
Jens

Lionel MARTIN schrieb:
> Hello,
> 
> Just to confrm that I have the same symptom as yours when I was 
> developing on Win32: when a module couldn't load, the only thing I could 
> get was a bare "Can't load module", without any explanation.
> Then, th eonly thing I could do was trying to isolate the problem, 
> progressively stripping stuff from my code.
> I never investigated so as to get the true perl diagnose.
> 
> Lionel.
> 
> ----- Original Message ----- From: "Jens Helweg" <helweg <at> gmx.de>
> To: <modperl <at> perl.apache.org>
> Sent: Thursday, June 28, 2007 12:09 PM
> Subject: Where is Perl compilation output when using modperl ?
> 
> 
>> Hi erveryone,
>>
>> I am using modperl2 with apache2 on win32 (activestate Perl 5.8). I
(Continue reading)

Permalink | Reply | 0 comments |

Gmane