Re: while - modperl 2.0/Apache 2.0
Udlei Nattis wrote: > hi, > > this problem is stranger > when i use apache 1.3/modperl 1.27 this problem don't exist > > i think problem is because thread in apache2 or modperl2 That's the thing. I've had the same behavior with apache 1.3/modperl 1.27, so I don't think this has anything to do with Apache or mod_perl. (This is on linux) > lynx dont have problem because is other instance > if you open 2 instances of mozilla you dont have problem > but if you open one mozilla and 5 tab navigator of instance > problem persist > > []s > > nattis > Stas Bekman wrote: > >> Stas Bekman wrote: >> >>> Alessandro Forghieri wrote: >>> Greetings. I have observed the same behavior (on win32). Scripts that are invoked from the same browser through the same URL appear to bind to the same perl thread and are therefore serialized. Changing the URL appears to bind the request to a different thread. (My observation regarded access from a different : Udei's experience shows that a URL change suffices). I have often wondered wether this is incidental or specified behaviour. >>> >>> >>> >>> >>> OK, I've returned to this problem. And the bug is in Apache 2.0 not >>> mod_perl. I was able to reproduce the serialization problem with a >>> plain cgi-bin script. Will report to the httpd-dev list and hopefully >>> it'll be resolved in the future version. >> >> >> >> I'm taking my words back. I did some more testing and the same problem >> can be reproduced with Apache 1.3. So I have tried different browsers >> and chased the problem to be a browser's fault. Here is the status on >> linux: >> >> Opera, Mozilla, Galeon - serialize the requests to the same URL. >> Konqueror, lynx- run both in parallel. >> >> Luckily I didn't sent the bogus bug report to httpd-dev ;) >> >> __ >> 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
hi, this problem is stranger when i use apache 1.3/modperl 1.27 this problem don't exist i think problem is because thread in apache2 or modperl2 lynx dont have problem because is other instance if you open 2 instances of mozilla you dont have problem but if you open one mozilla and 5 tab navigator of instance problem persist []s nattis Stas Bekman wrote: > Stas Bekman wrote: > >> Alessandro Forghieri wrote: >> >>> Greetings. >>> >>> I have observed the same behavior (on win32). >>> >>> Scripts that are invoked from the same browser through the same URL >>> appear >>> to bind to the same perl thread and are therefore serialized. >>> Changing the URL appears to bind >>> the request to a different thread. (My observation regarded access >>> from a >>> different : Udei's experience shows that a URL change >>> suffices). >>> >>> I have often wondered wether this is incidental or specified behaviour. >> >> >> >> OK, I've returned to this problem. And the bug is in Apache 2.0 not >> mod_perl. I was able to reproduce the serialization problem with a >> plain cgi-bin script. Will report to the httpd-dev list and hopefully >> it'll be resolved in the future version. > > > I'm taking my words back. I did some more testing and the same problem > can be reproduced with Apache 1.3. So I have tried different browsers > and chased the problem to be a browser's fault. Here is the status on > linux: > > Opera, Mozilla, Galeon - serialize the requests to the same URL. > Konqueror, lynx- run both in parallel. > > Luckily I didn't sent the bogus bug report to httpd-dev ;) > > __ > 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
Stas Bekman wrote: > Alessandro Forghieri wrote: > >> Greetings. >> >> I have observed the same behavior (on win32). >> >> Scripts that are invoked from the same browser through the same URL >> appear >> to bind to the same perl thread and are therefore serialized. Changing >> the URL appears to bind >> the request to a different thread. (My observation regarded access from a >> different : Udei's experience shows that a URL change >> suffices). >> >> I have often wondered wether this is incidental or specified behaviour. > > > OK, I've returned to this problem. And the bug is in Apache 2.0 not > mod_perl. I was able to reproduce the serialization problem with a plain > cgi-bin script. Will report to the httpd-dev list and hopefully it'll be > resolved in the future version. I'm taking my words back. I did some more testing and the same problem can be reproduced with Apache 1.3. So I have tried different browsers and chased the problem to be a browser's fault. Here is the status on linux: Opera, Mozilla, Galeon - serialize the requests to the same URL. Konqueror, lynx- run both in parallel. Luckily I didn't sent the bogus bug report to httpd-dev ;) __ 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
Alessandro Forghieri wrote: > Greetings. > > I have observed the same behavior (on win32). > > Scripts that are invoked from the same browser through the same URL appear > to bind to the same > perl thread and are therefore serialized. Changing the URL appears to bind > the request to a different thread. (My observation regarded access from a > different : Udei's experience shows that a URL change suffices). > > I have often wondered wether this is incidental or specified behaviour. OK, I've returned to this problem. And the bug is in Apache 2.0 not mod_perl. I was able to reproduce the serialization problem with a plain cgi-bin script. Will report to the httpd-dev list and hopefully it'll be resolved in the future version. __ 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
Greetings. I have observed the same behavior (on win32). Scripts that are invoked from the same browser through the same URL appear to bind to the same perl thread and are therefore serialized. Changing the URL appears to bind the request to a different thread. (My observation regarded access from a different : Udei's experience shows that a URL change suffices). I have often wondered wether this is incidental or specified behaviour. Cheers, alf
Re: while - modperl 2.0/Apache 2.0
thanks ;) now i understand to run in others browser instances you need change url example: http://127.0.0.1/hello-world?a http://127.0.0.1/hello-world?b http://127.0.0.1/hello-world?c http://127.0.0.1/hello-world?d /tmp/test123 1505: 162 <- thread 1505: 155 <- thread 1578: 146 1505: 131 <- thread 1578: 124 1505: 163 <- thread 1505: 156 <- thread 1578: 147 1505: 132 :)) bye nattis Stas Bekman wrote: > 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: 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: 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: 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