read environent variable
i m trying to read environment variable in perl using
$OSTY = $ENV{OSTYPE};
this will return os type as "linux" or "solaris". but when i try for cygwin
it returns empty string. is the some other syntax of way of finding value of
env variable in cygwin
--
View this message in context:
http://www.nabble.com/read-environent-variable-t1348295.html#a3606968
Sent from the mod_perl - General forum at Nabble.com.
Re: read environent variable
Hi,
this is a mod_perl forum please ask perl questions on perl-monks or any
other perl-support forum and if it is a perlbug file a bug using perlbug
to p5p.
Tom
cyg_win_user wrote:
> i m trying to read environment variable in perl using
>
> $OSTY = $ENV{OSTYPE};
> this will return os type as "linux" or "solaris". but when i try for cygwin
> it returns empty string. is the some other syntax of way of finding value of
> env variable in cygwin
> --
> View this message in context:
> http://www.nabble.com/read-environent-variable-t1348295.html#a3606968
> Sent from the mod_perl - General forum at Nabble.com.
>
>
signature.asc
Description: OpenPGP digital signature
No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
Tom, > As a sidenote often it is not really desired/dangerous to run image > creation as a mod_perl handler because of the nature of perl, memory > allocated once is never freed until the process shutdowns or is killed > (by your Apache::SizeLimit handler). Ah, you got me worried there... How in your opinion should one do creation of images in a mod_perl environment. Think of captcha's, on-the-fly images, etc.? I am very interested to hear opinions about this (just before I am going to use this heavily ;-). Regards, Frank
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
Well image creation in mod_perl is not a bad idea if you ensure that the process is killed after it succeeded a certain memory. The problem in case of mod-perl/httpd is that that if every httpd-process is eating 20 MB of space only because you have created once an image. You must ensure that only very view processes of your apache are used to create images and /me thinks this could be accomplished best using the following setup. 1. light-weight httpd to server static content 2. mod-perl enabled httpd to serve dynamic content beside images 3. mod-perl enabled httpd to server images with few processes (e.g. MaxChild 5). This ensures that you can answer 5 image creation request simultaneously but your system will never use more than 100 MB to create images. If your system is not stressed heavily 1 and 3 could be run in one server. Tom Frank Maas wrote: > Tom, > > >>As a sidenote often it is not really desired/dangerous to run image >>creation as a mod_perl handler because of the nature of perl, memory >>allocated once is never freed until the process shutdowns or is killed >>(by your Apache::SizeLimit handler). > > > Ah, you got me worried there... How in your opinion should one do creation of > images in a mod_perl environment. Think of captcha's, on-the-fly images, etc.? > > I am very interested to hear opinions about this (just before I am going to > use this heavily ;-). > > Regards, > Frank > > signature.asc Description: OpenPGP digital signature
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
Please note that this is not only true for Image-Creation but also if you are restoring large string contents in a variable (e.g. after processing a file-upload). Tom Frank Maas wrote: > Tom, > > >>As a sidenote often it is not really desired/dangerous to run image >>creation as a mod_perl handler because of the nature of perl, memory >>allocated once is never freed until the process shutdowns or is killed >>(by your Apache::SizeLimit handler). > > > Ah, you got me worried there... How in your opinion should one do creation of > images in a mod_perl environment. Think of captcha's, on-the-fly images, etc.? > > I am very interested to hear opinions about this (just before I am going to > use this heavily ;-). > > Regards, > Frank > > signature.asc Description: OpenPGP digital signature
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
On 3/27/06 6:21 AM, "Tom Schindl" <[EMAIL PROTECTED]> wrote: > Please note that this is not only true for Image-Creation but also if > you are restoring large string contents in a variable (e.g. after > processing a file-upload). > > Tom > > Frank Maas wrote: >> Tom, >> >> >>> As a sidenote often it is not really desired/dangerous to run image >>> creation as a mod_perl handler because of the nature of perl, memory >>> allocated once is never freed until the process shutdowns or is killed >>> (by your Apache::SizeLimit handler). >> >> >> Ah, you got me worried there... How in your opinion should one do creation of >> images in a mod_perl environment. Think of captcha's, on-the-fly images, >> etc.? >> >> I am very interested to hear opinions about this (just before I am going to >> use this heavily ;-). Can you fork off a separate process to do this (that will die once it is completed)? Sean
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
Can you fork off a separate process to do this (that will die once it is completed)? The only place where forking is useful is where you want something to continue processing after sending the response back to the client. You can achieve the same effective result by calling $r->child_terminate() (assuming your using pre-fork). The currently running child exits at the end of the request freeing any memory it's allocated, and the main apache server process will fork a new child to replace it if needed. Carl
Re: syntax vs. style
Instead of using MP2 syntax, etc, we're still using: print "Content-type: $type\n\n"; print "blah"; and in sending redirects, we use stuff like: print "Location: $url\n\n"; Is this a problem or is it just bad style? What reasons are there to continue our port to use the correct response handler syntax, etc? < It's slightly slower. Effectively those headers have to be re-parsed by Apache::Registry. Another example is that $r->print is faster than a plain print. Although Apache::Registry gives a good speed boost by itself, you need to make use of the mod_perl API to actually get the best out of it. The next step from there is not using Apache::Registry at all, but putting mod_perl handlers into their own modules/packages. However there's more of a change here to other ways of working - for example you need to restart server to introduce code changes. Carl
Re: syntax vs. style
On Mon, 27 Mar 2006 14:08:38 +0100 "Carl Johnstone" <[EMAIL PROTECTED]> wrote: > The next step from there is not using Apache::Registry at all, but > putting mod_perl handlers into their own modules/packages. However > there's more of a change here to other ways of working - for example > you need to restart server to introduce code changes. Overall great advice in this thread, but I wanted to point out that with Apache2::Reload this isn't strictly the case. You can set it to reload certain modules or all without a server restart, however I personally wouldn't use it in production as there is very little benefit. - Frank Wiles <[EMAIL PROTECTED]> http://www.wiles.org -
Re: syntax vs. style
On Mar 27, 2006, at 9:42 AM, Frank Wiles wrote: Overall great advice in this thread, but I wanted to point out that with Apache2::Reload this isn't strictly the case. You can set it to reload certain modules or all without a server restart, however I personally wouldn't use it in production as there is very little benefit. Apache::Reload doesn't always work too. two scenarios a_ if you have stuff that happens in a BEGIN block, or stuff that references something in a begin block (example: module a: has a begin block that pulls config info from a DB. module b: on startup (after begin) parses that config info into a specific datastructure -- apache:restart won't help you if you have to modify a or b. ) b_ In the past , if you needed to make 20 changes to a file on your dev box to trace soemthing down, after 10 or so changes you could see a bunch of namespace issues come up. I *think* thats fixed now though. but it might not be. | - - - - - - - - - - - - - - - - - - - - | RoadSound.com / Indie-Rock.net | Collaborative Online Management And Syndication Tools | Launching March 2006 | - - - - - - - - - - - - - - - - - - - -
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
i generally don't like to do that in modperl unless i have enough webservers. i think its a bit of a waste of the mp resource. i do this: on upload, generate a thumbnail w/Image:Epeg (which is a super fast implementation of epeg. previously i compiled my own epeg tools and the perl mod is WAY faster ) and save the original have a cronjob that passes over new uploads and redoes the thumbnail and creates sized versions using the python imaging library ( much faster and way more powerful than the perl modules or image magick and way easier to code ) captchas - you can pregenerate a bunch then use rewrite to alias them. to me, its silly to generate them on the fly - its a rather tedious task. you can even have a cronjob create a new pool of captchas and a new map of filenames -> text in image every few hours if you want. i'm ok w/using image:epeg, because it just scans the image for info and doesn't read the whole thing into memory. i really hate doing image manipulation stuff in mod_perl or perl in general.
Re: PerlCleanupHandler in modperl 2
we should keep this on-list :)
Clinton Gormley wrote:
>>it ought to work, but it should be setting a per-server cleanup instead of a
>>per-request cleanup. see below.
>>
>
>
> Doh!
:)
>
>
>
>>basically cleanups are performed when memory allocated for different parts
>>of the server lifecycle is destroyed. so, httpd allocates memory for the
>>server, per-configuration, per-connection, and per-request. setting up a
>>cleanup handler on each will run the handler whenever the memory pool goes
>>out of scope.
>>
>
>
> Ok - this starts to make sense.
>
> What I'm trying to achieve is :
> - a child init handler which turns on caching (so that the process
>is owned by the right user)
> - a cleanup handler which cleans out the in memory cache at the end
>of each request
>
> I seem to be having a lot of trouble putting them in the same place...
you should be able to put them both in the same place
package My::Foo;
use Apache2::ServerUtil;
Apache2::ServerUtil->server->add_config('PerlChildInitHandler My::init');
Apache2::ServerUtil->server->add_config('PerlCleanupHandler My::cleanup');
sub handler {
...
and provided you PerlModule your package it _should_ work...
>
> In the config file :
> ---
> PerlRequire "/opt/apache/sites/obits/conf/startup.pl"
> ## This doesn't work :
> PerlChildInitHandler Obits::Dispatcher::activate_cache
it doesn't? that's very odd. if you can't do that then there's no reason
to have the PerlChildInitHandler, then, is there?
>
>
> SetHandler perl-script
> PerlResponseHandler Obits::Dispatcher
> ## This does work :
> PerlCleanupHandler Obits::Dispatcher::cleanup_cache
>
>
> In the startup file:
>
> use Apache2::ServerUtil;
> # this works:
> Apache2::ServerUtil->server->push_handlers(
>PerlChildInitHandler => \&activate_cache)
>
>
> But from here, I can't push a cleanup handler that will be called for
> every request, can I?
via add_config() would be the way I would handle that.
>
> I have it working by using the PerlChildInitHandler in the startup file
> and the PerlCleanupHandler in the apache config, but I would prefer to
> put both of these into the startup file.
using a startup file instead of the package should work, too. see
t/response/TestAPI/add_config.pm for an example.
>
> Is it possible? What am I missing?
just add_config() I think.
>
> thanks for your response Geoff
:)
--Geoff
RE: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
I use Image::Imlib2 for on the fly image creation and it works fine for me.
After the thumbnails are created, memory is restored to normal size.
Image::Imlib2 is also very vast and easy to code.
For filetypes that are not supported by imlib2, I use imagemagick which is
using some more memory but even there, memory is restored after the thumbnail
creation.
I also used it with a Treaded MPM and after 10 thumbnails and previews the
system only uses a few megabytes more memory ( with perlInterpMaxRequests set
to 20 and PerlInterpMax set to 8)
I think it is very useful to create thumbnails on the fly. It is maintenance
free, you can just copy images to your image directory and have them show up
immediately.
I run on a 2 gig Ram Pentium 2.66Ghz server with SUSE 9.3 with maxserver set to
20 with a front-end and a backend server. Never had any problems.
* This is how I use the thumbnail creation in MOD_PERL:
I check for the existence of an thumbnail and if not already created or
outdated, I create it and update the utime to the utime of the original file so
you can check if un update is needed.
Before I create a thumbnail, I generate a lock file which is removed
afterwards. If the images is corrupted or the process is killed during the
thumbnail creation, the lockfile exists so the process is not repeated.
This also prevent that two sessions are trying to generate a thumbnail from the
same image at the same time.
Here is some sample code from the resize routine:
### sub create_iml_resized ##
sub create_iml_resized {
my ( $self, $sourcefile, $cachedfile ) = @_;
# use lockfile to prevent more sessions trying to thumb the same file
# and prevent death-loops
$self->uselockfile($cachedfile, 'iml') or return;
my $maxsize = $self->{maxsize};
Image::Imlib2->set_cache_size(0);
my $image;
eval { $image = Image::Imlib2->load($sourcefile) };
if ($@ || !$image){
$status = "Error in opening image: $@";
return;
}
my $doctype = $self->{ext};
my $width = $image->get_width;
my $height = $image->get_height;
unless ( $height ){
$status = 'unknown dimensions, corrupted image' ;
return;
}
my $maxheight;
my $maxwidth;
my $ratio;
if ( $self->{fixedwidth} ){
$maxwidth = $maxsize;
$maxheight = $maxsize*1.5;
$ratio = $height/$width > 1.5 ? $height/$maxheight : $width/$maxwidth ;
} elsif ($maxsize > $fixedheight){
$maxheight = $maxsize;
$maxwidth = $maxsize*1.5;
$ratio = $width/$height > 1.5 ? $width/$maxwidth : $height/$maxheight;
} else {
$maxheight = $maxsize;
$maxwidth = $maxsize;
$ratio = $width > $height ? $width/$maxwidth : $height/$maxheight;
}
# image is needs resizing
if ( $height > $maxheight || $width > $maxwidth ){
my $tw = int( $width/$ratio );
my $th = int( $height/$ratio );
my $image2=$image->create_scaled_image($tw,$th); # Scale image
$image2->image_set_format("jpeg"); # Convert image to JPG
$image2->set_quality($self->{quality});
eval { $image2->save($cachedfile) };
if ($@){
$status = "Error in saving image: $@";
return;
}
# image size is ok but filetype is not JPEG
} elsif ( lc $doctype ne 'jpeg' || lc $doctype ne 'jpg' ){
$image->image_set_format("jpeg"); # Convert image to JPG
$image->set_quality($self->{quality});
$image->save($cachedfile);
# Filetype and size are OK so copy to thumb cache
} else {
copy($sourcefile,$cachedfile) or $status = "Copy failed: $!";
}
$self->cleanuplockfile();
return
}
Thomas den Braber
Re: syntax vs. style
Thanks guys - this is helpful.In reality, and running the ways things are, I already need to restart (or ::Reload) to introduce changes (moved to that paradigm last year) -- but I guess that beyond the efficiencies you point out here in using proper API (for handler, print, etc) and the rationale here, I'm trying to prioritize and scope my next effort if any, (for this project, at least), and then best approach the next project. Basically, I have packages that print headers for everything, and others that "print $foo;exit;" for everything. Ideally, I'll alter each of those to do it right, and get better mileage. And from there, I'll work on creating proper mod_perl handlers. Cheers,On 3/27/06, Frank Wiles <[EMAIL PROTECTED]> wrote: On Mon, 27 Mar 2006 14:08:38 +0100"Carl Johnstone" <[EMAIL PROTECTED]> wrote:> The next step from there is not using Apache::Registry at all, but > putting mod_perl handlers into their own modules/packages. However> there's more of a change here to other ways of working - for example> you need to restart server to introduce code changes. Overall great advice in this thread, but I wanted to point out that with Apache2::Reload this isn't strictly the case. You can set it to reload certain modules or all without a server restart, however I personally wouldn't use it in production as there is very little benefit. - Frank Wiles <[EMAIL PROTECTED]> http://www.wiles.org -
Re: syntax vs. style
Apache::Reload doesn't always work too. two scenarios ... I use Apache2::Reload myself for my development box. There's an extra scenario you missed out: 1. If you change the inheritance of the package, you'll get an error too. But having said that, I find Apache2::Reload very handy for easy and quick development.
Re: No image creation in mod_perl (was RE: Apache2/MP2 Segfaults ...)
Hey Carl, The only place where forking is useful is where you want something to continue processing after sending the response back to the client. You can achieve the same effective result by calling $r->child_terminate() (assuming your using pre-fork). The currently running child exits at the end of the request freeing any memory it's allocated, and the main apache server process will fork a new child to replace it if needed. This revelation of how Perl does not free up memory it allocates is worrying, especially as I do process large documents regularly. If I read you right, you are saying that $r->child_terminate will force the current thread to terminate, causing Apache to create a new thread. Is that right? I use 'threads' in place of 'processes' as I refer to the Windows implementation of Apache. Thanks.
Re: syntax vs. style
On Mar 27, 2006, at 10:06 PM, Foo Ji-Haw wrote: Apache::Reload doesn't always work too. two scenarios ... I use Apache2::Reload myself for my development box. There's an extra scenario you missed out: 1. If you change the inheritance of the package, you'll get an error too. But having said that, I find Apache2::Reload very handy for easy and quick development. i couldn't develop or test without it. its a great module and i find it indispensable with my own work. i just don't think its a good option for a production environment. others might disagree.
Using Apache Module for Homepage Handler
[sorry for length, I've been wanting to ask this for a while :)] Hello, I'm a bit new to coding with mod_perl (and I _am_ new to this list), and I have a question. :) I have it set up now where my default page is index.pl, and I've got some other links (e.g. contact/about/faq) that are also generated from perl scripts. (I have a directive that puts all .pl files through ModPerl::Registry) Reason they're mod_perl generated is that the index does a lot, and if the user is logged on it displays one thing; otherwise, something else, etc. I have other normal mod_perl modules that act as handlers for certain URIs, based on directives. But the more I learn, the more I see that I should probably stray away from individual files. (maybe not?) But I always wondered how people set-up mod_perl do deal with different links on a large site: does one use for every link possible? (yeah yeah, I know) Well, for the modules I learned how to parse the path_info and take from there what link needs to be processed. So I decided to make my default homepage a mod_perl module. Then I could parse path_info and dispatch to the appropriate 'handler' (or page renderer function) for things like [contact|faq| about]. Is that normal? Because I can't seem to get it to work. How does one set-up the Apache config? Is the PerlResponseHandler Blah::Main put under the directive for the document root? What would the document root be? How are these things typically dealt with when there is dynamic content (i.e. user-specific stuff) on the homepage? I have a feeling 'templating' is going to be the response. Yeah, I should probably start looking at that. :) (Right now it's just the no-no of having a class that generates different parts of the page, filled with a lot of HTML mixed with some Perl conditionals for user-specific stuff) Sorry for the length; as you can see, I'm a bit confused about the large site stuff. I have "Writing Apache Modules with Perl and C" and "Web Development with Apache and Perl by Theo Petersen," but it just seems that those books don't deal with full site stuff. The Eagle Book does some, but I haven't gotten my head around it all yet. (as if that isn't obvious) I'm learning, but it's a new way of thinking about web-presentation for me. Thanks, jab3
