Re: [patch] Problem using Apache::Session::SharedMem with Apache::Session::Flex
> Also, i suggest to add some tests into the distro in order to use also > Apache::Session::Flex All fixed in 0.6 Thanks. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Variables in memory.
Greetings, I'm having a problem with a script when accessed by multipile users. The script remembers the variables used by one user and passes them on to another user. What would be the best way to avoid this? Use sessions and hold the variables in a uniqe hash per session? Thank you.
Re: Variables in memory.
On Wed, 22 Sep 2004 08:01:12 -0700 [EMAIL PROTECTED] wrote: > Greetings, > > I'm having a problem with a script when accessed by multipile users. > The script remembers the variables used by one user and passes them on > to another user. What would be the best way to avoid this? Use > sessions and hold the variables in a uniqe hash per session? You are most likely using some global variables in your code. You'll want to check this page out: http://perl.apache.org/docs/1.0/guide/porting.html#Sometimes_it_Works__Sometimes_it_Doesn_t - Frank Wiles <[EMAIL PROTECTED]> http://www.wiles.org - -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
current modperl doesn't run with apache 2.0.51?
Hello everybody,
Please don't stone me, if my problem is too silly, but this is what I
get when running make test:
ulimit -c unlimited; /usr/bin/perl5.8.4 /inst/mod_perl-1.99_16/t/TEST
-bugreport -verbose=0
[warning] root mode: changing the files ownership to 'nobody' (65534:65534)
[warning] testing whether 'nobody' is able to -rwx /inst/mod_perl-1.99_16/t
"/usr/bin/perl5.8.4" -Mlib=/inst/mod_perl-1.99_16/Apache-Test/lib
-MApache::TestRun -e 'eval { Apache::TestRun::run_root_fs_test(65534,
65534, q[/inst/mod_perl-1.99_16/t]) }';
[warning] result: OK
[warning] the client side drops 'root' permissions and becomes 'nobody'
/usr/local/apache2/bin/httpd -d /inst/mod_perl-1.99_16/t -f
/inst/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS
using Apache/2.0.51 (prefork MPM)
waiting 120 seconds for server to start: .Syntax error on line 12 of
/inst/mod_perl-1.99_16/t/conf/httpd.conf:
Cannot load /inst/mod_perl-1.99_16/src/modules/perl/mod_perl.so into
server: /inst/mod_perl-1.99_16/src/modules/perl/mod_perl.so: undefined
symbol: Perl_Ipatchlevel_ptr
[ error]
server has died with status 255 (t/logs/error_log wasn't created, start
the server in the debug mode)
make: *** [run_tests] Error 143
Please what's wrong?
Petr.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Variables in memory.
Greetings, I'm having a problem with a script when accessed by multipile users. The script remembers the variables used by one user and passes them on to another user. What would be the best way to avoid this? Use sessions and hold the variables in a uniqe hash per session? Thank you. D
Re: ANNOUNCE: Apache::Qpsmtpd
On Tue, Sep 21, 2004 at 07:19:48PM +0100, Matt Sergeant wrote: > On 19 Sep 2004, at 10:34, Matt Sergeant wrote: > > >Last week I was at YAPC and attended mock's talk about building an > >SMTPd in mod_perl2/apache2. But before going I wanted to be able to > >build something like that for myself. So I wrote Apache:Qpsmtpd - a > >mod_perl2 handler that embeds Qpsmtpd (http://smtpd.develooper.com/) > > > > http://www.sergeant.org/Apache-Qpsmtpd/ > > > >It seems to mostly work, though if you want to play with it you'll > >need the current cvs of qpsmtpd. It's about 3 times faster than the > >qpsmtpd-forkserver that ships with qpsmtpd. > > Someone posted privately asking why I thought it was faster, but my > reply to them bounced (broken anti-spam system I think) so I'll reply > here: > > I think it's faster because it pre-forks. qpsmtpd-forkserver is just > naive - it forks once per connection. Plus I guess Apache does the I/O > for you, though I don't think that's really gaining me much - consider > the overheads of the bucket brigade vs Perl's readline. > > Matt. > I think there is the potential for an even better speed increase with a little reworking of how QPSMTPD works. Some of the stuff you're doing (the timeout bits you showed me) might be better left to Apache to handle. Also, you might want to try it with the threading MPM vs the preforking. Some OS's see a bit of improvement. Any idea where your bottleneck is? mock -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Variables in memory.
Hi, you'll have to give us more background information. I hope to get you right but using globals to pass things between request doesn't work because you can never tell which Apache-Child is used. This is true e.g. mp1 and mp2 with apache in prefork mode. Take this: 1. Apache-starts and forks to Apache-Children 1 and 2 2. User1 hits Apache-Child 1 and sets the global $FOO from 0 to 1 3. User2: 3.a. hits Apache-Child 2 and $FOO is 0 because User1 has set $FOO in Apache-Child2 or 3.b. hits Apache-Child 1 and $FOO is 1 because User1 has set $FOO to 1 When running with mp2 and worker mpm the case is slightly different: 1. Apache-starts and starts Apache-Child 1 which spawn Thread 1.1 and Thread 1.2 and Apache-Child 2 which spawn Thread 2.1 and Thread 2.2 2. User1 hits Apache-Child 1 Thread 1.1 and sets the global $FOO from 0 to 1 which is shared between the threads 3. User2 3.a. hits Apache-Child 1 Thread 1.2 $FOO is 1 because User1 has set $FOO to 1 3.b. hits Apache-Child 2 Thread 2.1 or Thread 2.2 $FOO is 0 because User1 has set $FOO to 1 in thread 1.1 and 1.2. See: http://perl.apache.org/docs/2.0/user/handlers/server.html#Server_Life_Cycle Essentially this means: You'll have to store the values you want to pass from user1 to user2 using some sort of persitence/cache system like e.g. BerkleyDB, shm, the filesystem, a database, ... . http://sourceforge.net/projects/perl-cache/ Hope that helps. Tom > Greetings, > > I'm having a problem with a script when accessed by multipile users. > The script remembers the variables used by one user and passes them on to > another user. > What would be the best way to avoid this? Use sessions and hold the > variables in a uniqe hash per session? > > Thank you. > > -- GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail +++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++ -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: current modperl doesn't run with apache 2.0.51?
Appending some config info: perl -v: v5.8.4 built for i686-linux-thread-multi uname -a: Linux sodomizatko 2.6.8.1 #2 Wed Sep 15 01:20:54 UTC 2004 i686 AMD Athlon(TM) XP 2200+ AuthenticAMD GNU/Linux -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl sometimes prints to error log instead of client
On Wed, 2004-09-22 at 02:00, Ryan Underwood wrote: > Here's the current config that's been whittled down Your config is pretty basic, so it must be something in the code that's causing it. > I've no idea what to try next. You need to discover how to reproduce the problem. I would start by finding a way to check where STDOUT is going, so that you can tell what requests were handled by the child process that starts writing to the error log and recreate them. Increase your logging as necessary in order to get all the parameters that are being sent in so that you can recreate them with your browser or a WWW::Mechanize script. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ANNOUNCE: Apache::Qpsmtpd
On 22 Sep 2004, at 17:34, mock wrote: I think there is the potential for an even better speed increase with a little reworking of how QPSMTPD works. Some of the stuff you're doing (the timeout bits you showed me) might be better left to Apache to handle. Also, you might want to try it with the threading MPM vs the preforking. Some OS's see a bit of improvement. Any idea where your bottleneck is? I removed the timeout stuff, and that was no faster. I tried the other MPM and it creeeaaahhheed rather spectacularly. No idea why. No time or inclination to debug :-) Matt. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: current modperl doesn't run with apache 2.0.51?
Petr Duchon wrote:
Hello everybody,
Please don't stone me, if my problem is too silly, but this is what I
get when running make test:
ulimit -c unlimited; /usr/bin/perl5.8.4 /inst/mod_perl-1.99_16/t/TEST
-bugreport -verbose=0
[warning] root mode: changing the files ownership to 'nobody' (65534:65534)
[warning] testing whether 'nobody' is able to -rwx /inst/mod_perl-1.99_16/t
"/usr/bin/perl5.8.4" -Mlib=/inst/mod_perl-1.99_16/Apache-Test/lib
-MApache::TestRun -e 'eval { Apache::TestRun::run_root_fs_test(65534,
65534, q[/inst/mod_perl-1.99_16/t]) }';
[warning] result: OK
[warning] the client side drops 'root' permissions and becomes 'nobody'
/usr/local/apache2/bin/httpd -d /inst/mod_perl-1.99_16/t -f
/inst/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS
using Apache/2.0.51 (prefork MPM)
waiting 120 seconds for server to start: .Syntax error on line 12 of
/inst/mod_perl-1.99_16/t/conf/httpd.conf:
Cannot load /inst/mod_perl-1.99_16/src/modules/perl/mod_perl.so into
server: /inst/mod_perl-1.99_16/src/modules/perl/mod_perl.so: undefined
symbol: Perl_Ipatchlevel_ptr
[ error]
server has died with status 255 (t/logs/error_log wasn't created, start
the server in the debug mode)
make: *** [run_tests] Error 143
Please what's wrong?
Petr, your report is far from being incomplete. Please see
http://perl.apache.org/bugs/
In *addition* to that information please send the output of
ldd /inst/mod_perl-1.99_16/src/modules/perl/mod_perl.so
Chances are that you have more than one perl installed on your system and
you have libperl.so in /usr/lib or another global path. And it gets loaded
instead of the libperl.so from the other perl that you've compiled
mod_perl with.
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Variables in memory.
Thomas Schindl wrote: When running with mp2 and worker mpm the case is slightly different: 1. Apache-starts and starts Apache-Child 1 which spawn Thread 1.1 and Thread 1.2 and Apache-Child 2 which spawn Thread 2.1 and Thread 2.2 2. User1 hits Apache-Child 1 Thread 1.1 and sets the global $FOO from 0 to 1 which is shared between the threads 3. User2 3.a. hits Apache-Child 1 Thread 1.2 $FOO is 1 because User1 has set $FOO to 1 3.b. hits Apache-Child 2 Thread 2.1 or Thread 2.2 $FOO is 0 because User1 has set $FOO to 1 in thread 1.1 and 1.2. That explanations serves as a good answer to the question. But... That's not what happens behind the scenes. - Apache threads have nothing to do with perl interpreters. - There is no 1:1 relationship between apache threads and perl interpreters. Inside one child process you can have 1 Apache thread, and 10 perl interpreters, and vice versa, 10 Apache threads and 1 perl interpreter. - Moreover, since interpreters live in pools, you can have several pools comprised of totally different/unrelated interpreters. - And all these could be used by Thread 1.1 if you are running under threaded apache. So one needs to talk about perl interpreters and not Apache threads. I hope it is not too confusing :) One day someone will chart the details for a better visual comprehension. In fact you can have perl interpreter pools with prefork-mpm too (because threads aren't relevant here at all). This feature, for example, allows two different developers use the same server with a totally different @INC. http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: current modperl doesn't run with apache 2.0.51?
Hello everybody! the problem was solved!
Upon Stas's advice, I sought more info and found that libperl was
compiled without threading support.
perl had threads, so now everything is OK, except for the frozen-bubble
game. It needs SDL, which doesn't
seem to like threads. My wife is hooked on this game, so I'll have to
explain...
Anyway, sorry for the trouble.
Thank You,
petr.
Stas Bekman wrote:
Petr Duchon wrote:
Hello everybody,
Please don't stone me, if my problem is too silly, but this is what I
get when running make test:
ulimit -c unlimited; /usr/bin/perl5.8.4 /inst/mod_perl-1.99_16/t/TEST
-bugreport -verbose=0
[warning] root mode: changing the files ownership to 'nobody'
(65534:65534)
[warning] testing whether 'nobody' is able to -rwx
/inst/mod_perl-1.99_16/t
"/usr/bin/perl5.8.4" -Mlib=/inst/mod_perl-1.99_16/Apache-Test/lib
-MApache::TestRun -e 'eval { Apache::TestRun::run_root_fs_test(65534,
65534, q[/inst/mod_perl-1.99_16/t]) }';
[warning] result: OK
[warning] the client side drops 'root' permissions and becomes 'nobody'
/usr/local/apache2/bin/httpd -d /inst/mod_perl-1.99_16/t -f
/inst/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS
using Apache/2.0.51 (prefork MPM)
waiting 120 seconds for server to start: .Syntax error on line 12 of
/inst/mod_perl-1.99_16/t/conf/httpd.conf:
Cannot load /inst/mod_perl-1.99_16/src/modules/perl/mod_perl.so into
server: /inst/mod_perl-1.99_16/src/modules/perl/mod_perl.so:
undefined symbol: Perl_Ipatchlevel_ptr
[ error]
server has died with status 255 (t/logs/error_log wasn't created,
start the server in the debug mode)
make: *** [run_tests] Error 143
Please what's wrong?
Petr, your report is far from being incomplete. Please see
http://perl.apache.org/bugs/
In *addition* to that information please send the output of
ldd /inst/mod_perl-1.99_16/src/modules/perl/mod_perl.so
Chances are that you have more than one perl installed on your system
and you have libperl.so in /usr/lib or another global path. And it
gets loaded instead of the libperl.so from the other perl that you've
compiled mod_perl with.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl sometimes prints to error log instead of client
On Wed, Sep 22, 2004 at 01:58:53PM -0400, Perrin Harkins wrote: > > You need to discover how to reproduce the problem. I would start by > finding a way to check where STDOUT is going, Unfortunately, I have searched for a way to do this and came up with nothing. I have a feeling STDOUT is being prematurely closed or else redirected somehow to STDERR, but I don't know of any way to verify this through debug output. Does perl have a function to check the status of a file descriptor? > so that you can tell what > requests were handled by the child process that starts writing to the > error log and recreate them. Increase your logging as necessary in > order to get all the parameters that are being sent in so that you can > recreate them with your browser or a WWW::Mechanize script. The parameters are identical to runs where it works. I can refresh the page repeatedly. Sometimes it completely works 10/10 times. Other times it works 5/10 times or 0/10 times. It seems completely random but if I could just figure out what's happening to STDOUT it might shed some light on the trouble. -- Ryan Underwood, <[EMAIL PROTECTED]> -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Variables in memory.
Stas Bekman wrote: Thomas Schindl wrote: When running with mp2 and worker mpm the case is slightly different: 1. Apache-starts and starts Apache-Child 1 which spawn Thread 1.1 and Thread 1.2 and Apache-Child 2 which spawn Thread 2.1 and Thread 2.2 2. User1 hits Apache-Child 1 Thread 1.1 and sets the global $FOO from 0 to 1 which is shared between the threads 3. User2 3.a. hits Apache-Child 1 Thread 1.2 $FOO is 1 because User1 has set $FOO to 1 3.b. hits Apache-Child 2 Thread 2.1 or Thread 2.2 $FOO is 0 because User1 has set $FOO to 1 in thread 1.1 and 1.2. That explanations serves as a good answer to the question. But... That's not what happens behind the scenes. - Apache threads have nothing to do with perl interpreters. - There is no 1:1 relationship between apache threads and perl interpreters. Inside one child process you can have 1 Apache thread, and 10 perl interpreters, and vice versa, 10 Apache threads and 1 perl interpreter. - Moreover, since interpreters live in pools, you can have several pools comprised of totally different/unrelated interpreters. - And all these could be used by Thread 1.1 if you are running under threaded apache. So one needs to talk about perl interpreters and not Apache threads. I hope it is not too confusing :) One day someone will chart the details for a better visual comprehension. In fact you can have perl interpreter pools with prefork-mpm too (because threads aren't relevant here at all). This feature, for example, allows two different developers use the same server with a totally different @INC. http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ Thanks Stas for the full explaination. Indeed I didn't know exactly what's really going on behind the scences. Thanks for your explaination I'm always learning something new when reading your answers. Still on the one hand I recognize what you're trying to tell me, on the other hand could you give me more information about how things like this could be accomplished or better the other wayround how could I prevent things like 1 thread with 10 perl-interpreters and vice versa if I don't want it? Tom -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Variables in memory.
Tom Schindl wrote: Thanks Stas for the full explaination. Indeed I didn't know exactly what's really going on behind the scences. Thanks for your explaination I'm always learning something new when reading your answers. Thanks :) Still on the one hand I recognize what you're trying to tell me, on the other hand could you give me more information about how things like this could be accomplished or better the other wayround how could I prevent things like 1 thread with 10 perl-interpreters and vice versa if I don't want it? You use interpreter pool size control directives: http://perl.apache.org/docs/2.0/user/config/config.html#Threads_Mode_Specific_Directives You don't need to prevent anything. It's just that if your server uses very little modperl and mostly doing static requests, you can have just a few perl interpreters around (in the threaded mpm) and many more threads. The above link explains how to set a limit on the size of the pool. I know we need to write some docs explaining the nuances, since I've done this more than once here on the list. But all that after mp2 is 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Variables in memory.
Stas Bekman wrote: Tom Schindl wrote: Thanks Stas for the full explaination. Indeed I didn't know exactly what's really going on behind the scences. Thanks for your explaination I'm always learning something new when reading your answers. Thanks :) Still on the one hand I recognize what you're trying to tell me, on the other hand could you give me more information about how things like this could be accomplished or better the other wayround how could I prevent things like 1 thread with 10 perl-interpreters and vice versa if I don't want it? You use interpreter pool size control directives: http://perl.apache.org/docs/2.0/user/config/config.html#Threads_Mode_Specific_Directives You don't need to prevent anything. It's just that if your server uses very little modperl and mostly doing static requests, you can have just a few perl interpreters around (in the threaded mpm) and many more threads. The above link explains how to set a limit on the size of the pool. I know we need to write some docs explaining the nuances, since I've done this more than once here on the list. But all that after mp2 is released. Oh. I see great. I dive into it when I have more time and I'm sure I'll come up with some "silly" questions, be prepared. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Variables in memory.
Greetings, The problem is that the script takes more than 3 or 4 seconds to execute sometimes. So we have a script that takes 3-4 seconds to execute, each varaiable is defined with my $var. and when the script ends it resets the value of the variables using undef. If multiple users execute the script within those 3-4 seconds will the variables still be shared between them? What would be the best way to avoid this ? Thank you all for the quick answers and great information. - Original Message - From: "Tom Schindl" <[EMAIL PROTECTED]> To: "Stas Bekman" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, September 22, 2004 3:59 PM Subject: Re: Variables in memory. > Stas Bekman wrote: > > > Tom Schindl wrote: > > > >> Thanks Stas for the full explaination. Indeed I didn't know exactly > >> what's really going on behind the scences. Thanks for your > >> explaination I'm always learning something new when reading your > >> answers. > > > > > > Thanks :) > > > >> Still on the one hand I recognize what you're trying to tell me, on > >> the other hand could you give me more information about how things > >> like this could be accomplished or better the other wayround how > >> could I prevent things like 1 thread with 10 perl-interpreters and > >> vice versa if I don't want it? > > > > > > You use interpreter pool size control directives: > > http://perl.apache.org/docs/2.0/user/config/config.html#Threads_Mode_Specifi c_Directives > > > > > > You don't need to prevent anything. It's just that if your server uses > > very little modperl and mostly doing static requests, you can have > > just a few perl interpreters around (in the threaded mpm) and many > > more threads. The above link explains how to set a limit on the size > > of the pool. > > > > I know we need to write some docs explaining the nuances, since I've > > done this more than once here on the list. But all that after mp2 is > > released. > > > Oh. I see great. I dive into it when I have more time and I'm sure I'll > come up with some "silly" questions, be prepared. > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Variables in memory.
On Wed, 2004-09-22 at 19:37, [EMAIL PROTECTED] wrote: > So we have a script that takes 3-4 seconds to execute, each variable is > defined with my $var. and when the script ends it resets the value of the > variables using undef. > > If multiple users execute the script within those 3-4 seconds will the > variables still be shared between them? No, absolutely not. No variables are ever shared between mod_perl processes. What can happen though is that variables retain their values between runs of the script in the same process. This only happens with "my" variables if you are accidentally creating closures. If you think this is happening to you, please post some code that demonstrates the problem so we can have a look and give you advice. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
Joe Orton wrote:
On Fri, Sep 17, 2004 at 04:15:23PM -0400, Stas Bekman wrote:
So is that the right skip rule (hoping that 2.0.52 will fix NetBSD:
my $should_skip =
($^0 eq /^OpenBSD$/i && !need_min_apache_version('2.0.51')) ||
($^0 eq /^NetBSD$/i && !need_min_apache_version('2.0.52'));
That logic is correct w.r.t the APR issue, yes.
Joe, as 2.0.52 is about to be released. Can that fix for NetBSD applied to
the 0.9 trunch (and head) if it does the trick? Thanks.
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl sometimes prints to error log instead of client
Ok, here's something interesting. I am using basic authentication on the mod_perl vhost. I use netcat to connect to it: $ echo 'GET /perl/?action=login HTTP/1.1 Host: test.foo.com ' | nc www 80 Sometimes a try comes back with the following correct response: HTTP/1.1 401 Authorization Required Date: Thu, 23 Sep 2004 03:19:46 GMT Server: Apache/1.3.31 Ben-SSL/1.55 (Debian GNU/Linux) mod_gzip/1.3.26.1a PHP/4.3.4 mod_perl/1.29 WWW-Authenticate: Basic realm="Development" Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 18d 401 Authorization Required Authorization Required This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required. 0 However, occasionally a try comes back with _nothing_; the netcat connection is just closed, and the response ends up in the error log instead. The thing is, this is an Apache response, having nothing to do with my code at all (even though I do have PerlSendHeaders Off to manage my own HTTP headers aside from authentication). The client's connection is dropped before Apache even gets into the mod_perl code. The weirdest thing about this is that even though it seems to have nothing to do with my code now, it _only_ happens on the mod_perl vhost. Not on any other vhosts, even ones running the same program in CGI mode. Any hypotheses? -- Ryan Underwood, <[EMAIL PROTECTED]> -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl sometimes prints to error log instead of client
I might have figured it out. The program wasn't closing STDOUT at the end of printing stuff to the client. Is this a known boo-boo? Anyway, I haven't seen the problem yet after restarting apache, so I'm crossing my fingers now. -- Ryan Underwood, <[EMAIL PROTECTED]> -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
