Re: END subroutine in Apache::Registry
Hi Jim, The documentation is neither unclear nor confusing. However, the implication was not obvious (well... not obvious enough) when I first read this section three years ago. If you're sincere about wanting suggestions, here's mine: of course :) In addition to understanding the behavior of END blocks in Apache::Registry scripts, a script writer must realize that any module invoked via use or include may work differently than its designer intended, if that module contains END blocks. great, will add that. Though I've noticed that it works this way only if you 'use'. if you 'require' it's being ignored completely (not even run on the shutdown), is it just me or do you see the same? seems like a bug to me, unless I'm missing something. Thanks Jim! -Jim On Fri, 12 Jul 2002, Stas Bekman wrote: Jim Schueler wrote: I just read the fine print: Apache::Registry runs BEGIN subroutines just once per child process, but END routines run every time a script is run. The implication is that an otherwise robust module may behave unexpectedly when it's imported by an Apache::Registry script. Doesn't this cause problems for mod_perl users? There is no mention of this issue in either mod_perl_to_cgi or mod_perl_traps. Admittedly, most of the code in my END subroutines should probably be refactored into OO DESTROY subroutines anyways. But if not burned, I've been significantly scalded by this belated realization. I don't see anything on CPAN that can be easily applied to all of the modules that written. I'll happily fill that void, but I must be overlooking the obvious solution. Can anyone provide any insights? Please read: http://perl.apache.org/release/docs/1.0/guide/porting.html#END_blocks The special case is for registry scripts that include END blocks. If the the explanation at the above URL is unclear/confusing, please suggest how to improve it. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: TIPool / multiple database connections
Perrin Harkins wrote:
Elizabeth Mattijsen wrote:
Hmm... but you won't be able to fetch the $dbh from the thread. It
can only live in _that_ thread. You cannot pass objects between
threads. But you _can_ send queries to that thread, fetch a jobid for
that job and then obtain whatever was returned as a Perl datastructure.
(if anyone knows of a way to pass objects between threads, I'd really
would like to know)
Hmmm... That could really throw a wrench in things. If you have an
object based on a hash, and you share that hash, and you re-bless the
object in each thread, does that work? What if the hash contains
references to other variables. Do they need to be explicity shared as
well?
That's what I meant. Probably non need for Thread::Pool, at all. use a
shared datastructure, maintain a list of free and busy items and simply
hand pointers inside this datastructure to the threads asking for an
item. e.g.:
package DBI::Pool;
use threads::shared;
my @pool : shared;
sub init {} # pre-populate pool with N connections
sub get {} # return a ref to $dbh, grow the pool if needed
sub put {} # move the pointer from the busy list to the free list
won't this work? I guess Perrin is right in respect that the whole item
needs to be shared (deep-shared). can we have such an attribute/function
that will automatically traverse the datastructure and share it all? or
is this the case already with 'shared'?
Now since we want to have various connections, it can be:
my %pools : shared;
where each key is a unique identifier, compiled from the dbi connect's
DSN string and a value is the actual pool.
BTW, there is no more need for Apache prefix in Apache::DBI, this can be
a generic Pool class. I guess Apache::DBI can subclass DBI::Pool and add
things like connect_on_init(), but just to build the initial pool when
the process starts.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Persistent Net::Telnet Objects in Apache2/mod_perl2
French, Shawn wrote: Stas Bekman wrote: It seems that you are after the same functionality as Apache::DBI, you want a pool of items that you want to be able to choose from. Look for threads::shared (perl 5.8.0), just create a shared hash with keys that you use for the map and the values for the actual connection objects. YES!!! That is exactly what I need! Where do I find perl 5.8.0 and threads::shared? I need a perl binary for windows since I'm without a compiler... Wait about one more week and it's going to be released. e.g. see http://use.perl.org/ As for the apache notes, I hope your right that it would be easy to implement, otherwise I can't upgrade to apache2 without some _huge_ workarounds... which are always nice to avoid :) Apache 2.0 wasn't released yet in any case. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Getting to the Guide PDF on the new website
At 09:24 PM 7/13/2002, Stas Bekman wrote: Gunther Birznieks wrote: I agree! It is great work. It looks really slick. :) Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the latest guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. eh? what do you mean? it's all there, go to: http://perl.apache.org/docs/1.0/guide/index.html click on the pdf button in the right upper corner and you get this: http://perl.apache.org/docs/1.0/guide/guide.pdf Notice though, that parts non-specific to mod_perl 1.0 has now moved to http://perl.apache.org/docs/general/index.html Oh I see it does work. I suppose the PDF buttons on every page is what confused me though. So if you go to the front-page of the docs section, just the front-page gets generated in a PDF, if you go to a page within the guide, then just that section gets generated. The only PDF icon that actually generates a full guide (and it is inconsistent with what the rest of the website PDF icons do) is the actually guide.pdf. A constructive suggestion would be that the icon for PDF on the main guide page should explicitly say PDF of entire guide or something other than the simple PDF icons on all the other pages of the website. Or perhaps remove the PDF icons entirely off the rest of the website. After all, who really wants to generate a PDF of a single HTML page they already read? __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ Office: (65) 64791172 Mobile: (65) 96218290
Re: TIPool / multiple database connections
At 02:57 PM 7/16/02 +, Stas Bekman wrote:
Perrin Harkins wrote:
Hmmm... That could really throw a wrench in things. If you have an
object based on a hash, and you share that hash, and you re-bless the
object in each thread, does that work? What if the hash contains
references to other variables. Do they need to be explicity shared as well?
That's what I meant. Probably non need for Thread::Pool, at all. use a
shared datastructure, maintain a list of free and busy items and simply
hand pointers inside this datastructure to the threads asking for an item.
e.g.:
package DBI::Pool;
use threads::shared;
my pool : shared;
sub init {} # pre-populate pool with N connections
sub get {} # return a ref to $dbh, grow the pool if needed
sub put {} # move the pointer from the busy list to the free list
Hmmm... as long as you do this _before_ the (Apache) threads get started,
this might work. I still haven't got my mind entirely around what one is
allowed to do, what you can do and is allowed, what you can't do but is
allowed and crashes, and what in principle is possible but you're barred
from because of e.g. prototyping getting in the way.
won't this work? I guess Perrin is right in respect that the whole item
needs to be shared (deep-shared). can we have such an attribute/function
that will automatically traverse the datastructure and share it all? or is
this the case already with 'shared'?
Good question. I don't think it is deep shared and that's why it probably
doesn't work. The way Thread::Queue::Any (which is the transport medium
for Thread::Pool) handles this, is by serializing any data structure with
Storable, pass that around and deserialize that on the other end.
Now since we want to have various connections, it can be:
my %pools : shared;
where each key is a unique identifier, compiled from the dbi connect's
DSN string and a value is the actual pool.
That's an approach. If you could actually share the $sth objects. About
which I have my doubts.
BTW, there is no more need for Apache prefix in Apache::DBI, this can be a
generic Pool class. I guess Apache::DBI can subclass DBI::Pool and add
things like connect_on_init(), but just to build the initial pool when the
process starts.
DBI::Pool would be ok. But unless I'm wrong about the sharing issues,
you're going to be stuck, at least with this version of Perl, with
serializing between threads.
Liz
Re: Getting to the Guide PDF on the new website
Gunther Birznieks wrote: At 09:24 PM 7/13/2002, Stas Bekman wrote: Gunther Birznieks wrote: I agree! It is great work. It looks really slick. :) Unfortunately, the mod_perl guide documentation area has lost functionality. I wanted to download the latest guide before my 23 hour flight to the USA (to read on the flight) and was dismayed to find hours before my flight that it is impossible to get a full HTML or full PDF download of the entire guide anymore... You can get a PDF of single pages (of which I don't know the reason?), but the guide itself is quite hard. eh? what do you mean? it's all there, go to: http://perl.apache.org/docs/1.0/guide/index.html click on the pdf button in the right upper corner and you get this: http://perl.apache.org/docs/1.0/guide/guide.pdf Notice though, that parts non-specific to mod_perl 1.0 has now moved to http://perl.apache.org/docs/general/index.html Oh I see it does work. I suppose the PDF buttons on every page is what confused me though. So if you go to the front-page of the docs section, just the front-page gets generated in a PDF, if you go to a page within the guide, then just that section gets generated. The only PDF icon that actually generates a full guide (and it is inconsistent with what the rest of the website PDF icons do) is the actually guide.pdf. A constructive suggestion would be that the icon for PDF on the main guide page should explicitly say PDF of entire guide or something other than the simple PDF icons on all the other pages of the website. Or perhaps remove the PDF icons entirely off the rest of the website. After all, who really wants to generate a PDF of a single HTML page they already read? Well, if you don't want to read the PDF of a single page, that doesn't mean that others think the same. People like reading of the paper and not the screen. The new site is based on docsets stacking. Each root node includes chapters and other docsets. Each root node builds the pdf of all its immediate leaf nodes (chapters). Each leaf (chapter) builds a pdf of itself. Notice that root nodes do *not* include chapters included in the nested docsets, otherwise the very root pdf will be of 50MB in size. I don't really follow your confusion. If you read the chapter 'help' and you click on the pdf icon you get this chapter in pdf. if you are reading the index page and click on the pdf you get the whole thing. It's just more flexible now than it used to be. I guess the only confusion might be with docsets that include no chapters, but only other docsets, so if you click on the pdf icon at /docs/1.0/ you get an almost empty pdf. But I guess people will learn how things work and find the infrastructure useful. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: TIPool / multiple database connections
Liz, should we move this thread to the perl-ithreads list so we can get some answers from the threads gurus? or p5p? I doubt Arthur is listening on this list. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: sql-relay
What problem is that? I don't think there's much you can do beyond re-connecting, which Apache::DBI does. Well, the thing about SQLRelay is that it pools database connections, which is good when you want to have plenty of persistent connections to different databases. My only problem with it is that it doesn't seem to support prepared_cached statements... Cheers, -- IT'S TIME FOR A DIFFERENT KIND OF WEB Jean-Michel Hiver - Software Director [EMAIL PROTECTED] +44 (0)114 255 8097 VISIT HTTP://WWW.MKDOC.COM
Re: Working Directory
Matt Sergeant wrote: On Fri, 12 Jul 2002, Stas Bekman wrote: Josh Bernstein wrote: After just upgrading to mod_perl2 with Apache2. My current @INC path includes a . on the end, which should reference the current working directory, and therefore correctly locate include locate in the script's working directory. The problem is that the Working Directory is set to /. My question is how can I set the working directory to be the location of where the script is running. (This would make mod_perl correctly locate file that I have included in the running script ie: require ./file.pl) Can this be done from within Apache? I've tried variations of PerlSetEnv but I can't seem to get it to work. I've even read the mod_perl2 user's guide. Thanks for your help.. chdir is not a thread-safe function, (there is only one CWD per application) therefore the new ModPerl::Registry doesn't chdir to the dir of the script. We have discussed various workarounds on the dev list, but none of them has been applied yet. http://mathforum.org/discussions/epi-search/modperl-dev.html (search for 'chdir thread') Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Apache SSL - how to start it in -X mode
How to restart SSL Apache in -X mode? Thanks in advance for your help Mark
Re: Apache SSL - how to start it in -X mode
[EMAIL PROTECTED] wrote: How to restart SSL Apache in -X mode? This is a wrong forum. See: http://httpd.apache.org/lists.html#http-users __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Working Directory
At 06:10 PM 7/16/02 +, Stas Bekman wrote: Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. Check out Arthur's article on Perl.com: http://www.perl.com/pub/a/2002/06/11/threads.html Liz
Re: Working Directory
Elizabeth Mattijsen wrote: At 06:10 PM 7/16/02 +, Stas Bekman wrote: Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. Check out Arthur's article on Perl.com: http://www.perl.com/pub/a/2002/06/11/threads.html I read the article ;) The article doesn't say that there is going to be a module that will do all this work for you. I just wanted to share the happy news that such a module is about to emerge. Most of the people don't care how things are implemented, they just want to know that the API they use is thread-safe, which is how it should be with chdir() and friends. Though you realize that that this wrapper will incur a certain overhead, which needs to be benchmarked. And if that overhead is of any significant value, we should provide a switch to turn if off for those who don't rely on chdir() and therefore can get a better performance. I'm talking mainly about the Registry family in this case, but I can see that this functionality could be provided on the mod_perl core level (PerlSafeCwd flag?). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [ANNOUNCE] Petal 0.1
At 10:41 AM 07/16/2002 +0100, Jean-Michel Hiver wrote: Hi list, I am glad to announce the first release of Petal, the Perl Template Attribute Language module. You will find a rather copious documentation here: http://search.cpan.org/doc/JHIVER/Petal-0.1/lib/Petal.pm It should be pretty stable, however the more people have a play with it the more likely I am to be aware of potential bugs :-) Tell me what you think! Interesting work, cheers. I'm curious though, why you've chosen to implement it as a handler for XML::Parser rather than as a SAX Handler (or even better, a Filter)? What SAX buys (among other things) is the ability for folks to invisibly use whatever XML parser is installed, including a pure Perl implementation. Doing Petal as a SAX Filter would mean that it would be totally easy to add it to the mix in things like AxKit and custom SAX pipeline publishing systems. So, doing complex, multi-stage transformations like My::NonXML::SAXGenerator - Petal - SomeXSLT - SomeOtherXSLT come for free. Anyway, just random thoughts, really. Petal seems nice and it seems a shame to lock it in the XML::Parser-based-one-off jail. -kip Kip Hampton Perl and XML: http://xml.com/pub/q/perlxml AxKit: http://axkit.org/ Join Us In San Diego! http://conferences.oreillynet.com/os2002/ http://conferences.oreillynet.com/cs/os2002/view/e_sess/2533
worker thread
We are trying to use:
1) Apache 2.0.39 compiled with the option --with-mpm=worker
2) with modperl 2.0
under Sun Solaris 2.8 with Perl 5.8 RC2.
Although everything seems to work fine, the creation of a custom worker
thread takes more or less 2 minutes.
Here below a section of the code used:
my $t1 = new Thread(\my_thread,'t1');
my $t2 = new Thread(\my_thread,'t2');
$t1-join();
$t2-join();
sub my_thread{
my $name = shift;
print Im $name\n
return $name: done\n;
}
In the example above, each new thread call takes about 2 minutes.
Thanks for any help,
Lino
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Pasquale Pagano
CNR - Istituto di Elaborazione della Informazione
Via G. Moruzzi, 1 - 56124 Pisa,Italy
Area della Ricerca CNR di Pisa
Tel +39 050 3152891
E-mail: [EMAIL PROTECTED]
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
Re: duplicate output with Registry.pm
Hi, It happens with the printenv script also. Again, I did this to myself before, but I can't remember how I fixed it. It was something very simple. Thanks, Eric My http.conf perl stuff = # mod_perl config PerlRequire /usr/local/apache/conf/Start.pl PerlFreshRestart On PerlInitHandler Apache::StatINC PerlSetVar StatINC_UndefOnReload On Alias /perl /usr/local/apache/perl PerlWarn On PerlModule Apache::Registry Location /perl PerlHandler Apache::Registry::handler SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location Alias /perlrun /usr/local/apache/PerlRun Location /perlrun SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On Options +ExecCGI /Location http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: duplicate output with Registry.pm
--On Tuesday, July 16, 2002 06:44:10 -0400 Eric Frazier [EMAIL PROTECTED] wrote: Hi, It happens with the printenv script also. Again, I did this to myself before, but I can't remember how I fixed it. It was something very simple. Thanks, Seems like Location /perl will happily match urls such as /perlrun. Maybe you want to add trailing slashes to your Location and Alias directives. Eric My http.conf perl stuff = # mod_perl config PerlRequire /usr/local/apache/conf/Start.pl PerlFreshRestart On PerlInitHandler Apache::StatINC PerlSetVar StatINC_UndefOnReload On Alias /perl /usr/local/apache/perl PerlWarn On PerlModule Apache::Registry Location /perl PerlHandler Apache::Registry::handler SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location Alias /perlrun /usr/local/apache/PerlRun Location /perlrun SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On Options +ExecCGI /Location http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant -- Eric Cholet
relative path not accepted in mod_perl2 ?
I just upgraded to apache2 and mod_perl1.99 and the first big difference I noticed is that I can include my libraries using relative pathes any more. Until now I had my mainprogram and its library/ies in the same path. like # ls edit.* edit.lib.pl edit.pl and in edit.pl I had the line require './edit.pl'; this worked fine with mod_perl1.27 now I receive a error like this: [Tue Jul 16 15:56:33 2002] [error] 25772: ModPerl::Registry: `Can't locate ./edit.lib.pl at /data/apache/htdocs/goldfisch/edit.pl line 24' and I need to specify the full path in the require-command. While this is not a real problem its a suprising behaviour .. peter -- mag. peter pilsl IT-Consulting tel: +43-699-1-3574035 fax: +43-699-4-3574035 [EMAIL PROTECTED]
Re: duplicate output with Registry.pm
Hi, I will try that out. It was something like that, it even rings a bell a bit. Thanks! I will let you know. Eric At 03:51 PM 7/16/02 +0200, Eric Cholet wrote: --On Tuesday, July 16, 2002 06:44:10 -0400 Eric Frazier [EMAIL PROTECTED] wrote: Hi, It happens with the printenv script also. Again, I did this to myself before, but I can't remember how I fixed it. It was something very simple. Thanks, Seems like Location /perl will happily match urls such as /perlrun. Maybe you want to add trailing slashes to your Location and Alias directives. Eric My http.conf perl stuff = # mod_perl config PerlRequire /usr/local/apache/conf/Start.pl PerlFreshRestart On PerlInitHandler Apache::StatINC PerlSetVar StatINC_UndefOnReload On Alias /perl /usr/local/apache/perl PerlWarn On PerlModule Apache::Registry Location /perl PerlHandler Apache::Registry::handler SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location Alias /perlrun /usr/local/apache/PerlRun Location /perlrun SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On Options +ExecCGI /Location http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant -- Eric Cholet http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: worker thread
Pasquale Pagano wrote:
We are trying to use:
1)Apache 2.0.39 compiled with the option --with-mpm=worker
2)with modperl 2.0
under Sun Solaris 2.8 with Perl 5.8 RC2.
Although everything seems to work fine, the creation of a custom worker
thread takes more or less 2 minutes.
Here below a section of the code used:
my $t1 = new Thread(\my_thread,'t1');
my $t2 = new Thread(\my_thread,'t2');
$t1-join();
$t2-join();
sub my_thread{
my $name = shift;
print I'm $name\n
return $name: done\n;
}
In the example above, each new thread call takes about 2 minutes.
May I ask, why do you create these threads? Under worker you already
have the threads created for you and and the perl interpreters handed to
you when you need them.
BTW, what happens if you run the same code from the command line?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: relative path not accepted in mod_perl2 ?
just found out the deeper reason - mod_perl now always has path=/ which is unexpected behaviour. While I can filter out the actual path from the cgi-environment I dont understand this .. thnx, peter On Tue, Jul 16, 2002 at 04:12:02PM +0200, [EMAIL PROTECTED] wrote: I just upgraded to apache2 and mod_perl1.99 and the first big difference I noticed is that I can include my libraries using relative pathes any more. Until now I had my mainprogram and its library/ies in the same path. like # ls edit.* edit.lib.pl edit.pl and in edit.pl I had the line require './edit.pl'; this worked fine with mod_perl1.27 now I receive a error like this: [Tue Jul 16 15:56:33 2002] [error] 25772: ModPerl::Registry: `Can't locate ./edit.lib.pl at /data/apache/htdocs/goldfisch/edit.pl line 24' and I need to specify the full path in the require-command. While this is not a real problem its a suprising behaviour .. peter -- mag. peter pilsl IT-Consulting tel: +43-699-1-3574035 fax: +43-699-4-3574035 [EMAIL PROTECTED] -- mag. peter pilsl IT-Consulting tel: +43-699-1-3574035 fax: +43-699-4-3574035 [EMAIL PROTECTED]
R: worker thread
From the command line, it works very well.
We are impleminting a very complex digital library system.
In same cases, we want to start parallel threads in order to minimize the
wait.
Let me try to explain with an example.
'A' start 4 threads, each of which prepares, and sends a request to another
server, and then collects its result. When all threads will be terminated,
'A' will merge the 4 results.
Is now more clear?
-Messaggio originale-
Da: Stas Bekman [mailto:[EMAIL PROTECTED]]
Inviato: mercoledi 17 luglio 2002 00.13
A: Pasquale Pagano
Cc: [EMAIL PROTECTED]
Oggetto: Re: worker thread
Pasquale Pagano wrote:
We are trying to use:
1)Apache 2.0.39 compiled with the option --with-mpm=worker
2)with modperl 2.0
under Sun Solaris 2.8 with Perl 5.8 RC2.
Although everything seems to work fine, the creation of a custom worker
thread takes more or less 2 minutes.
Here below a section of the code used:
my $t1 = new Thread(\my_thread,'t1');
my $t2 = new Thread(\my_thread,'t2');
$t1-join();
$t2-join();
sub my_thread{
my $name = shift;
print I'm $name\n
return $name: done\n;
}
In the example above, each new thread call takes about 2 minutes.
May I ask, why do you create these threads? Under worker you already
have the threads created for you and and the perl interpreters handed to
you when you need them.
BTW, what happens if you run the same code from the command line?
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Purify, Perl and mod_perl
I've looked at Rational's Purify: http://www.rational.com/products/purify_unix/index.jsp, and although their web page says only works for C, C++, Java and a few others, I've seen this page: http://www.perlpod.com/stable/perlhack.html on getting Perl work with with Purify. My question is this...can I run my application using this purified perl under mod_perl to track down potential memory leaks and other problems? Are there any issues with running Perl for testing with Purify on a mod_perl enabled webserver? Thanks for the advice. --Dan
Apache::Registry and Apache::PerlRun
question, can i have both Registry and PerlRun running in the same environment? i have my cgi scripts running under Apache::Registry in one directory, and want to run a legacy cgi script under PerlRun in another directory. is this possible? matt
Re: relative path not accepted in mod_perl2 ?
On Tue, 16 Jul 2002 16:30:16 +0200, [EMAIL PROTECTED] said: P just found out the deeper reason - mod_perl now always has path=/ P which is unexpected behaviour. While I can filter out the actual path P from the cgi-environment I dont understand this .. See [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/smansheezhing/[EMAIL PROTECTED] -- Ilya Martynov (http://martynov.org/)
Re: Apache::Registry and Apache::PerlRun
Boex,Matthew W. wrote: can i have both Registry and PerlRun running in the same environment? i have my cgi scripts running under Apache::Registry in one directory, and want to run a legacy cgi script under PerlRun in another directory. is this possible? Yes, no problem at all. - Perrin
Re: relative path not accepted in mod_perl2 ?
[EMAIL PROTECTED] wrote: just found out the deeper reason - mod_perl now always has path=/ which is unexpected behaviour. While I can filter out the actual path from the cgi-environment I dont understand this .. See the parallel thread on the same topic. http://mathforum.org/epigone/modperl/smansheezhing Things will work as expected by the time mod_perl 2.0 is released. [funny that mathforum's engine has mixed this thread with a thread with the same title but from 5 years ago. Looks like the time has crossed itself] -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Registry and Apache::PerlRun
Boex,Matthew W. wrote: question, can i have both Registry and PerlRun running in the same environment? i have my cgi scripts running under Apache::Registry in one directory, and want to run a legacy cgi script under PerlRun in another directory. is this possible? matt of course. That's how it works. You can even run the same scripts under different handlers. Have you tried and it didn't work for you? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Purify, Perl and mod_perl
Carwheel, Dan wrote: although their web page says only works for C, C++, Java and a few others, I've seen this page: http://www.perlpod.com/stable/perlhack.html on getting Perl work with with Purify. That page is about getting Perl's C executable to work with Purify, not using Purify to check your perl code. My question is this...can I run my application using this purified perl under mod_perl to track down potential memory leaks and other problems? You probably don't have any memory leaks. Most things that people refer to as leaks are just normal growth. A leak is when an area of memory gets lost because the program that allocated it forgets to free it. Growth is when your program uses variables in such a way that it needs more memory over time. The latter is pretty common. Doing things like eval'ing code, reading variable length data into strings, and keeping other data structures that are affected by changes in user input or data over time will often lead to this. If you have out-of-control memory growth, you should try finding it the old-fashioned way: take things out until it stops. Then, if you find a little section that causes growth and you can't understand why, post it here and someone may be able to explain it. A number of the most common sources of memory growth are explained in the guide: http://perl.apache.org/docs/1.0/guide/performance.html#Improving_Performance_by_Prevention - Perrin
Re: R: worker thread
Pasquale Pagano wrote: From the command line, it works very well. We are impleminting a very complex digital library system. In same cases, we want to start parallel threads in order to minimize the wait. Let me try to explain with an example. 'A' start 4 threads, each of which prepares, and sends a request to another server, and then collects its result. When all threads will be terminated, 'A' will merge the 4 results. Is now more clear? sure, thanks your problem is that you use the *old* threads (5005threads, pre-5.6.0), whereas mod_perl 2.0 is using ithreads (5.6.0+). my $t2 = new Thread(\my_thread,'t2'); ^^^ do 'perldoc threads' with perl-5.8.0 __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: R: worker thread
At 11:19 PM 7/16/02 +, Stas Bekman wrote:
From the command line, it works very well.
We are impleminting a very complex digital library system.
In same cases, we want to start parallel threads in order to minimize the
wait.
Let me try to explain with an example.
'A' start 4 threads, each of which prepares, and sends a request to another
server, and then collects its result. When all threads will be terminated,
'A' will merge the 4 results.
Is now more clear?
You should be able to use Thread::Pool for this.
$pool = Thread::Pool-new(
{
workers = 10, # or higher or lower, max simultaneous requests
do = sub {fetch from URL and return it},
} );
jobid = ();
push( jobid,$pool-job( $_ ) ) foreach url;
foreach (jobid) {
my $result = $pool-result; # do whatever you want with result X
}
your problem is that you use the *old* threads (5005threads, pre-5.6.0),
whereas mod_perl 2.0 is using ithreads (5.6.0+).
my $t2 = new Thread(\my_thread,'t2');
do 'perldoc threads' with perl-5.8.0
Actually, to add to the confusion: only the Thread.pm and Thread::Signal.pm
modules are old 5.005threads modules. All the other Thread:: namespace
modules (except Malcolm Beattie's old version of Thread::Pool on CPAN) are
new ithreads modules. Only the true pragma modules threads.pm and
threads::shared.pm have remaind untouched. This was changed last week, as
described in Rafael's p5p
summary http://use.perl.org/article.pl?sid=02/07/15/0732235 ;-)
Liz
Re: Purify, Perl and mod_perl
Perrin Harkins wrote: [...] My question is this...can I run my application using this purified perl under mod_perl to track down potential memory leaks and other problems? You probably don't have any memory leaks. Most things that people refer to as leaks are just normal growth. A leak is when an area of memory gets lost because the program that allocated it forgets to free it. or cannot free it because of the closure or a circular reference, which seems to be the case with the bug in Apache::Request reported by Dave Rolsky. [...] A number of the most common sources of memory growth are explained in the guide: http://perl.apache.org/docs/1.0/guide/performance.html#Improving_Performance_by_Prevention Plus Apache::Leak, whose reports should be carefully analyzed because not everything that it reports as a leak is actually a leak: http://perl.apache.org/docs/1.0/guide/debug.html#How_can_I_find_out_if_a_mod_perl_code_has_a_memory_leak __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: Purify, Perl and mod_perl
I understand. But, given a new 'purified' perl binary I could build using Purify, would it allow me to diagnose or trace memory leaks back to my Perl code? I'm asking from a theoretical basis here, since I agree with you, I doubt I have any memory leaks. Thanks. --Dan -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 16, 2002 11:09 AM To: Carwheel, Dan Cc: '[EMAIL PROTECTED]' Subject: Re: Purify, Perl and mod_perl Carwheel, Dan wrote: although their web page says only works for C, C++, Java and a few others, I've seen this page: http://www.perlpod.com/stable/perlhack.html on getting Perl work with with Purify. That page is about getting Perl's C executable to work with Purify, not using Purify to check your perl code. My question is this...can I run my application using this purified perl under mod_perl to track down potential memory leaks and other problems? You probably don't have any memory leaks. Most things that people refer to as leaks are just normal growth. A leak is when an area of memory gets lost because the program that allocated it forgets to free it. Growth is when your program uses variables in such a way that it needs more memory over time. The latter is pretty common. Doing things like eval'ing code, reading variable length data into strings, and keeping other data structures that are affected by changes in user input or data over time will often lead to this. If you have out-of-control memory growth, you should try finding it the old-fashioned way: take things out until it stops. Then, if you find a little section that causes growth and you can't understand why, post it here and someone may be able to explain it. A number of the most common sources of memory growth are explained in the guide: http://perl.apache.org/docs/1.0/guide/performance.html#Improving_Performance _by_Prevention - Perrin
R: R: worker thread
Ok, as you have seen in my first e-mail, I have installed Perl 5.8.0 RC2.
Now, I'm moving to RC3 and and tomorrow I will tell you what happens.
Thanks for the moment,
Lino
-Messaggio originale-
Da: Elizabeth Mattijsen [mailto:[EMAIL PROTECTED]]
Inviato: martedi 16 luglio 2002 17.32
A: Stas Bekman; Pasquale Pagano
Cc: [EMAIL PROTECTED]
Oggetto: Re: R: worker thread
At 11:19 PM 7/16/02 +, Stas Bekman wrote:
From the command line, it works very well.
We are impleminting a very complex digital library system.
In same cases, we want to start parallel threads in order to minimize the
wait.
Let me try to explain with an example.
'A' start 4 threads, each of which prepares, and sends a request to
another
server, and then collects its result. When all threads will be terminated,
'A' will merge the 4 results.
Is now more clear?
You should be able to use Thread::Pool for this.
$pool = Thread::Pool-new(
{
workers = 10, # or higher or lower, max simultaneous requests
do = sub {fetch from URL and return it},
} );
@jobid = ();
push( @jobid,$pool-job( $_ ) ) foreach @url;
foreach (@jobid) {
my $result = $pool-result; # do whatever you want with result X
}
your problem is that you use the *old* threads (5005threads, pre-5.6.0),
whereas mod_perl 2.0 is using ithreads (5.6.0+).
my $t2 = new Thread(\my_thread,'t2');
do 'perldoc threads' with perl-5.8.0
Actually, to add to the confusion: only the Thread.pm and Thread::Signal.pm
modules are old 5.005threads modules. All the other Thread:: namespace
modules (except Malcolm Beattie's old version of Thread::Pool on CPAN) are
new ithreads modules. Only the true pragma modules threads.pm and
threads::shared.pm have remaind untouched. This was changed last week, as
described in Rafael's p5p
summary http://use.perl.org/article.pl?sid=02/07/15/0732235 ;-)
Liz
problem compiling modperl2.0
I am trying to create a test environment for modperl2.0/apache2/perl5.8 under RedHat7.3. As root, I did the first step, download using the cvs to get the modperl-2.0, httpd-2.0 and apr, apr-util (placed in httpd-2.0/srclib). make make install is fine. I using rsync to get the Perl, and the 'make's are fine and linked to /root/bleedperl/bin/perl. The install LWP under the new perl is also fine. Now come to the modperl2.0: root /root/bleedperl/bin/perl Makefile.PL MP_AP_PREFIX=/root/httpd-2.0 Reading Makefile.PL args from ARGV MP_AP_PREFIX = /root/httpd-2.0 Configuring Apache/2.0.40-dev mod_perl/1.99_05-dev Perl/v5.8.0 And a bunch of the following !!! Unable to open /root/httpd-2.0/include/apr.h: No such file or directory Please help! Harry Zhu GreatLodge.com
Re: problem compiling modperl2.0
Harry Zhu wrote: I am trying to create a test environment for modperl2.0/apache2/perl5.8 under RedHat7.3. As root, I did the first step, download using the cvs to get the modperl-2.0, httpd-2.0 and apr, apr-util (placed in httpd-2.0/srclib). make make install is fine. I using rsync to get the Perl, and the 'make's are fine and linked to /root/bleedperl/bin/perl. The install LWP under the new perl is also fine. Now come to the modperl2.0: root /root/bleedperl/bin/perl Makefile.PL MP_AP_PREFIX=/root/httpd-2.0 Reading Makefile.PL args from @ARGV MP_AP_PREFIX = /root/httpd-2.0 Configuring Apache/2.0.40-dev mod_perl/1.99_05-dev Perl/v5.8.0 And a bunch of the following !!! Unable to open /root/httpd-2.0/include/apr.h: No such file or directory Have you configured httpd-2.0 already? do that first before moving onto modperl __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [modperl2] Perl Connection Handlers for SSL connections
Pete Rothermel wrote:
I've got the example echo() handler working for a non-HTTP protocol as
outlined on the new web site:
http://perl.apache.org/docs/2.0/user/handlers/handlers.html#Command__Protocol__Phases
Anybody have a similar example for the same protocol handler over SSL?
the echo protocol working over the socket skips filters, so it won't
work with SSL.
at the above URL scroll down to the Apache::Eliza2 example, which uses
bucket brigades and therefore should work over SSL.
I didn't have a chance to document it yet, but for simple things you
just change the code inside this snippet:
if ($data) {
$data =~ s/[\r\n]*$//;
$last++ if $data =~ /good bye/i;
$data = $eliza-transform( $data ) . \n\n;
$bucket = APR::Bucket-new($data);
}
the rest most likely will stay unmodified.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
while - modperl 2.0/Apache 2.0
hi
sorry my english
i have one problem
when i open 2 browsers intance and access my perl script
instance 1 run script OK
instance 2 waiting instance 1 finalize to run :/
i need run simultane 2 instance
(modperl 2.0 dev 5 / perl 8 rc 3 / apache 2.0 prefork or worker )
example:
#!/usr/bin/perl
use Apache2;
$| = 1;
my $r = Apache-request;
$r-content_type(text/html);
$r-send_http_header;
$r-print(Apache::get_server_version().br);
# only for Apache Pre-Fork MPM
#if (Apache::MPM_IS_THREADED) {
# my $id = APR::OS::thread_current();
# print current thread id: $id;
#}
#else {
# print current process id: $$;
#}
$i = 0;
while ($i 20) {
$r-print($i.br\n);
$i++;
sleep 1;
}
thanks
Udlei Nattis
www.nobol.com.br
Re: while - modperl 2.0/Apache 2.0
Udlei Nattis wrote:
hi
sorry my english
i have one problem
when i open 2 browsers intance and access my perl script
instance 1 run script OK
instance 2 waiting instance 1 finalize to run :/
i need run simultane 2 instance
(modperl 2.0 dev 5 / perl 8 rc 3 / apache 2.0 prefork or worker )
how many servers do you run? Are you testing this in the single server
mode? Seems that you run only one server or only one process with one
thread.
a few comments regarding the code (irrelevant to your problem):
#!/usr/bin/perl
use Apache2;
this should go into startup/httpd.conf.
$| = 1;
my $r = Apache-request;
that should be just:
my $r = shift;
since your code is wrapped into sub handler { }.
what you are doing is expensive under threads.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Working Directory
Sounds great? Does he have anything that I could play with? I'm really dying for that chdir(), my programmer says he depends on that functionality. I'd even volunteer to do some benchmarks and what not associated with the extra overhead of making the function thread safe. If its not really yet, what do you feel is currently the best work around? I've read through the archives and I'm just try to figure which one to use... -Josh Stas Bekman wrote: Elizabeth Mattijsen wrote: At 06:10 PM 7/16/02 +, Stas Bekman wrote: Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. Check out Arthur's article on Perl.com: http://www.perl.com/pub/a/2002/06/11/threads.html I read the article ;) The article doesn't say that there is going to be a module that will do all this work for you. I just wanted to share the happy news that such a module is about to emerge. Most of the people don't care how things are implemented, they just want to know that the API they use is thread-safe, which is how it should be with chdir() and friends. Though you realize that that this wrapper will incur a certain overhead, which needs to be benchmarked. And if that overhead is of any significant value, we should provide a switch to turn if off for those who don't rely on chdir() and therefore can get a better performance. I'm talking mainly about the Registry family in this case, but I can see that this functionality could be provided on the mod_perl core level (PerlSafeCwd flag?). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Working Directory
Josh Bernstein wrote: Sounds great? Does he have anything that I could play with? I'm really dying for that chdir(), my programmer says he depends on that functionality. I'd even volunteer to do some benchmarks and what not associated with the extra overhead of making the function thread safe. He should probably announce it soon, when he returns from vacation. why don't you test with prefork for now? and Apache::compat + Apache::Registry from 1.x? If its not really yet, what do you feel is currently the best work around? I've read through the archives and I'm just try to figure which one to use... there are no workarounds to having a thread-safe cwd, other than using full paths. -Josh Stas Bekman wrote: Elizabeth Mattijsen wrote: At 06:10 PM 7/16/02 +, Stas Bekman wrote: Arthur told me he either had, or was going to fix this (on IRC). Yup, Arthur is working on an external package (ex::threads::safecwd?) which should solve this problem. Viva Arthur! I'll keep you updated once it gets released. Check out Arthur's article on Perl.com: http://www.perl.com/pub/a/2002/06/11/threads.html I read the article ;) The article doesn't say that there is going to be a module that will do all this work for you. I just wanted to share the happy news that such a module is about to emerge. Most of the people don't care how things are implemented, they just want to know that the API they use is thread-safe, which is how it should be with chdir() and friends. Though you realize that that this wrapper will incur a certain overhead, which needs to be benchmarked. And if that overhead is of any significant value, we should provide a switch to turn if off for those who don't rely on chdir() and therefore can get a better performance. I'm talking mainly about the Registry family in this case, but I can see that this functionality could be provided on the mod_perl core level (PerlSafeCwd flag?). __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: while - modperl 2.0/Apache 2.0
Udlei Nattis wrote:
how many servers do you run?
worker:
IfModule worker.c
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
/IfModule
prefork:
IfModule prefork.c
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
/IfModule
now i change my styles lines
i using:
package Apache::HelloWorld;
#LoadModule perl_module modules/mod_perl.so
#PerlSwitches -Mlib=modperl-2.0/examples/lib
##optional
#PerlModule Apache2
#PerlModule Apache::compat
#Location /hello-world
#SetHandler modperl
#PerlResponseHandler Apache::HelloWorld
#/Location
use strict;
use Apache::RequestRec (); #for $r-content_type
use Apache::RequestIO (); #for $r-puts
use Apache::Const -compile = 'OK';
$| = 1;
sub handler {
my $r = shift;
$r-content_type('text/plain');
#send_http_header API function does not exist in 2.0
my $i = 0;
while ($i 10) {
$r-print($i.\n);
sleep 1;
$i++;
}
$r-puts(__PACKAGE__); #print not yet implemented
return Apache::OK;
}
1;
and problem persist
instance 1 run ok
instance 2 waiting intance 1 finalize
thanks
nattis
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
ANNOUNCE: Apache::Session::Serialize::YAML 0.01
Just 8 lines of glue code to use YAML as a Apache::Session
serialization handler. Any suuggestions welcome, Thanks.
The URL
http://bulknews.net/lib/archives/Apache-Session-Serialize-YAML-0.01.tar.gz
has entered CPAN as
file: $CPAN/authors/id/M/MI/MIYAGAWA/Apache-Session-Serialize-YAML-0.01.tar.gz
size: 1499 bytes
md5: 31f6c30d707a56e2f37aca7e3a4cddf4
=head1 NAME
Apache::Session::Serialize::YAML - use YAML for serialization
=head1 SYNOPSIS
use Apache::Session::Flex;
tie %session, 'Apache::Session::Flex', $id, {
Store = 'MySQL',
Lock = 'Null',
Generate = 'MD5',
Serialize = 'YAML',
};
=head1 DESCRIPTION
Apache::Session::Serialize::YAML enables you to use YAML (YAML Ain't
Makeup Language [tm]) for Apache::Session serialization format. YAML
is a generic data serialization language for scripting languages, so
this module can be a good start to share session data with Ruby,
Python or PHP etc.
See http://www.yaml.org/ for details of YAML.
=head1 AUTHOR
Tatsuhiko Miyagawa Elt[EMAIL PROTECTED]gt
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
=head1 SEE ALSO
LYAML, LApache::Session, LApache::Session::PHP
=cut
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
New mod_perl site and oddness with IE
Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. An older version I tracked down with Google (http://www.apache.jp/perl/guide/performance.html) which is also 300K+ doesn't have the same problem - just to show that it's not purely the raw size of the page that is the problem. Just a little feedback for the new site (which is great, btw). If it's just me with the problem, I'll go find a rock to hide under. :) --Jim A number of the most common sources of memory growth are explained in the guide: http://perl.apache.org/docs/1.0/guide/performance.html#Improving_Perform ance_by_Prevention - Perrin
Re: New mod_perl site and oddness with IE
Not just you. I have the same problem under MSIE. Issac - Original Message - From: Jim Helm [EMAIL PROTECTED] To: 'Perrin Harkins' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 17, 2002 8:23 AM Subject: New mod_perl site and oddness with IE Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. An older version I tracked down with Google (http://www.apache.jp/perl/guide/performance.html) which is also 300K+ doesn't have the same problem - just to show that it's not purely the raw size of the page that is the problem. Just a little feedback for the new site (which is great, btw). If it's just me with the problem, I'll go find a rock to hide under. :) --Jim A number of the most common sources of memory growth are explained in the guide: http://perl.apache.org/docs/1.0/guide/performance.html#Improving_Perform ance_by_Prevention - Perrin
RE: New mod_perl site and oddness with IE
IE 5.5 on win2k as well. -Original Message- From: Issac Goldstand [mailto:[EMAIL PROTECTED]] Not just you. I have the same problem under MSIE. Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? http://perl.apache.org/docs/1.0/guide/performance.html#Improving_Perform
Re: New mod_perl site and oddness with IE
Jim Helm wrote: Has anyone else had problems with this particular page under IE (6.0.2600 under XP) being extremly slow to update when paging up/down? It works fine under Mozilla, and it's not a memory or cpu issue (checked with task manager already). And when I say slow, I mean a simple down cursor causes the visible portion of the page to get painted in 4 noticble steps/chunks. An older version I tracked down with Google (http://www.apache.jp/perl/guide/performance.html) which is also 300K+ doesn't have the same problem - just to show that it's not purely the raw size of the page that is the problem. Just a little feedback for the new site (which is great, btw). If it's just me with the problem, I'll go find a rock to hide under. :) Is the size of the page causes the trouble? I don't have IE to try so hopefully someone will help us out here. What happens if you shorten the content of the page? My guess is that IE simply cannot cope with a long page and the current complex stylesheet (because as say it works fine with the same page and a simpler stylesheet, which includes no layout instructions). Suggestions on how to fix that are welcome. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
