Re: while - modperl 2.0/Apache 2.0
ok, looks like your setup is fine.
Though I cannot seem to reproduce your problem. Indeed it seems that the
unbuffered output doesn't work. I'm checking on that. But I've devised a
better test that verifies that the requests aren't serialized. If you
run this hander by two clients at the same time, you should see the
lines in /tmp/test123 being interleaved by two processes. If this
doesn't happen and you get first 100 lines from process A followed by
process B's 100 lines than indeed we have a problem.
sub handler {
my $r = shift;
$r->content_type('text/plain');
local $| = 1;
open my $fh, ">>", "/tmp/test123" or die $!;
my $oldfh = select($fh); local $| = 1; select($oldfh);
my $i = 0;
while ($i < 100) {
$r->print("$$: $i \n");
print $fh "$$: $i \n";
sleep 1;
$i++;
}
$r->print(__PACKAGE__);
close $fh;
return Apache::OK;
}
If this indeed doesn't work, please try the suggestion at:
http://perl.apache.org/docs/1.0/guide/debug.html#Using_the_Perl_Trace
so you can see where the second process is stalled. If you don't get
anything from this approach try to attach to the second process with gdb
and see where it is stack on the C calls level. Though I suggest that
you test with prefork and this setup:
StartServers 2
MinSpareServers 2
MaxSpareServers 2
MaxClients 2
MaxRequestsPerChild 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: 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
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
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 > >
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: sql-relay
> It's harder if you want every query to be able to automatically retry on > another database if it fails. For that, you would need to add some > extra code to catch the exception, recognize it as a connection failure, > make a new connection, and retry the query. I don't see anything on the > SQL-Relay pages about this sort of ability. We crafted a module that does this for our Oracle databases. To save anybody else the effort, here are the errors we identified as connection errors that deserve a reconnection attempt: Oracle errors: ORA-00028 your session has been killed ORA-00603 ORACLE server session terminated by fatal error ORA-01034 ORACLE not available ORA-01092 ORACLE instance terminated. Disconnection forced ORA-03113 end-of-file on communication channel Other errors: -1 and 'Error Database disconnected' = dbh has been disconnected -- Kyle Oppenheim Tellme Networks, Inc. http://www.tellme.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 E[EMAIL PROTECTED]
This library is free software; you can redistribute it and/or modify
it under the same terms as Perl itself.
=head1 SEE ALSO
L, L, L
=cut
--
Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
Re: while - modperl 2.0/Apache 2.0
Udlei Nattis wrote:
how many servers do you run?
worker:
StartServers 2
MaxClients 150
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
prefork:
StartServers 5
MinSpareServers 5
MaxSpareServers 10
MaxClients 150
MaxRequestsPerChild 0
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
#
#SetHandler modperl
#PerlResponseHandler Apache::HelloWorld
#
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
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: 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: 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
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()."");
# 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."\n");
$i++;
sleep 1;
}
thanks
Udlei Nattis
www.nobol.com.br
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
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
[modperl2] Perl Connection Handlers for SSL connections
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? thanks Pete Rothermel
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
Give me the moron award please- Registry duplicates
Hi, Well I found the problem. I had replaced PerlHandler Apache::Registry with PerlHandler Apache::Registry::handler But I didn't really replace it, I forgot to delete the PerlHandler Apache::Registry line. DOH Half a day killed on that. Thanks, Eric Leading Edge Marketing Inc. 250-360-2992
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
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
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: 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: 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: 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: 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: 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: > 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 ?
> 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/)
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
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
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
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]
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: 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 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 >> >>PerlHandler Apache::Registry::handler >> SetHandler perl-script >> PerlHandler Apache::Registry >> PerlSendHeader On >> Options +ExecCGI >> >> >> Alias /perlrun /usr/local/apache/PerlRun >> >> >> >> SetHandler perl-script >> PerlHandler Apache::PerlRun >> PerlSendHeader On >> Options +ExecCGI >> >> >> >> 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
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
--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 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 > >PerlHandler Apache::Registry::handler > SetHandler perl-script > PerlHandler Apache::Registry > PerlSendHeader On > Options +ExecCGI > > > Alias /perlrun /usr/local/apache/PerlRun > > > > SetHandler perl-script > PerlHandler Apache::PerlRun > PerlSendHeader On > Options +ExecCGI > > > > http://www.kwinternet.com/eric > (250) 655 - 9513 (PST Time Zone) > > "Inquiry is fatal to certainty." -- Will Durant > > > -- Eric Cholet
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 PerlHandler Apache::Registry::handler SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI Alias /perlrun /usr/local/apache/PerlRun SetHandler perl-script PerlHandler Apache::PerlRun PerlSendHeader On Options +ExecCGI http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) "Inquiry is fatal to certainty." -- Will Durant
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: [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
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: 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: 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
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: 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
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
[ANNOUNCE] Petal 0.1
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! 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: 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: 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
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
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
