Username in Apache::AuthDBI
Hi, I must be a bit thick today, but I have thoroughly read the Apache::AuthDBI documentation, and even the source, and I haven't found any reference to where the username is put, once authenticated. Can somebody help me? JJ -- 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: Username in Apache::AuthDBI
Juan Julian Merelo Guervos wrote:
Hi,
I must be a bit thick today, but I have thoroughly read the
Apache::AuthDBI documentation, and even the source, and I haven't
found any reference to where the username is put, once authenticated.
Can somebody help me?
Help thyself... it's, as was to be expected, $ENV{REMOTE_USER}. Only it
would help the clueless, or the memoryless, that somebody reminded it
right there, in the documentation.
JJ
--
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: multiple developers on one Sever
Arun pandey schrieb: I guess the problem might be with your PerlHandler, coz Apache::Registry, caches all scripts, as a result certain global values will remain persistent. In such a case you might want to use Apache::PerlRun instead , which mimics mod_cgi by flushing the namespace at the every start of request. I understand this - but I want to use Apache::Registry for performance-reasons. How can I get different configurations in different Versions of my system? Should I use something like Config::Tiny? Or can I use Apache::PerlRun just for my config.pl - which I include via require 'config.pl'; ? Henning Thanks Arun - Original Message - From: "Henning Meyer" <[EMAIL PROTECTED]> To: Sent: Monday, December 20, 2004 11:10 PM Subject: multiple developers on one Sever Hello, I've got a mod_perl-Apache running, which hosts multiple developement-versions (of multiple CVS-developers) of a webapp. Therefore I've got this apache-config: Options +Includes XBitHack on SetHandler perl-script PerlHandler Apache::Registry PerlModule Apache::DBI PerlSendHeader On Options ExecCGI +Includes Order allow,deny Allow from all AllowOverride None Each version has its own config (like a seperate DB per developer). This is done by: require 'config.pl'; in each of the mod_perl-scripts. config.pl looks like this: #!/usr/bin/perl use strict; package myconf; use vars qw(%c); %c = (DB=>"henningsDB"}; # or tutmannsDB in tutmanns config.pl 1; The point is, that in each version everything may be the same except of the config.pl. But: Apache and mod_perl seem to mix up the configurations. The reason seems to be, that the configuration is just read once the process starts, and not each time a script is executed. What is a good workaround? Local ini-Files? Or something even better? Thanks Henning -- +++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl AKTION für Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben -- 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: multiple developers on one Sever
> I understand this - but I want to use Apache::Registry for > performance-reasons. How can I get different configurations in different > Versions of my system? > Should I use something like Config::Tiny? > Or can I use Apache::PerlRun just for my config.pl - which I include via > require 'config.pl'; > ? perhaps version checking will help you "use ProjectConfig 1.27" > Henning -- vad -- 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: multiple developers on one Sever
Well you are not stating which mp-version you are running but for: mp1: http://perl.apache.org/docs/1.0/guide/modules.html#Apache__PerlVINC___Allows_Module_Versioning_in_Location_blocks_and_Virtual_Hosts mp2: http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ Tom Henning Meyer wrote: Hello, I've got a mod_perl-Apache running, which hosts multiple developement-versions (of multiple CVS-developers) of a webapp. Therefore I've got this apache-config: Options +Includes XBitHack on SetHandler perl-script PerlHandler Apache::Registry PerlModule Apache::DBI PerlSendHeader On Options ExecCGI +Includes Order allow,deny Allow from all AllowOverride None Each version has its own config (like a seperate DB per developer). This is done by: require 'config.pl'; in each of the mod_perl-scripts. config.pl looks like this: #!/usr/bin/perl use strict; package myconf; use vars qw(%c); %c = (DB=>"henningsDB"}; # or tutmannsDB in tutmanns config.pl 1; The point is, that in each version everything may be the same except of the config.pl. But: Apache and mod_perl seem to mix up the configurations. The reason seems to be, that the configuration is just read once the process starts, and not each time a script is executed. What is a good workaround? Local ini-Files? Or something even better? Thanks Henning -- 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: compile problems
Hmm, I managed to get it to work with either -fpic or -fPIC after switching to shared perl. Also built with -m64. I noticed Apache (at least 2.0.52) configures/compiles for -fPIC automagically. But once it loads, it is BIG. (note lotta Apache modules, Apache::Request, CGI loaded via startup.pl). PID Size Share VSize Rss M Elapsed LastReq Srvd Client Virtual Host Request (first 64 chars) 5: 2525 94.4M 88.3M 94.4M 8.8M _ 0.000s 0.000s0 2: 2522 94.4M 88.3M 94.4M 8.8M _ 0.000s 0.000s0 4: 2524 94.4M 88.3M 94.4M 8.8M _ 0.000s 0.000s0 3: 2523 94.4M 88.3M 94.4M 8.8M _ 0.000s 0.000s0 0: 2520 94.4M 88.3M 94.4M 8.8M 1: 2521 108M 97.0M 108M 13.7M W 0.000s 0.000s0 10.1.54.95 testbox2 GET /sys-monitor HTTP/1.1 Total: 608169K ( 580M) size, 145465K ( 139M) approx real size (-shared) > -Original Message- > From: Matthew Berk [mailto:[EMAIL PROTECTED] > Sent: Monday, December 20, 2004 8:44 AM > To: modperl@perl.apache.org > Subject: Re: compile problems > > Found a solution worth writing about. I went through the perl > configuration interactively, specifying the following non-defaults: > > - compile perl as shared > - use gcc, not cc, as the compiler > - provide -fPIC to the compiler > *CONFIDENTIALITY NOTICE* This e-mail and any files or attachments may contain confidential and privileged information. If you have received this message in error, please notify the sender at the above e-mail address and delete it and all copies from your system. -- 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: multiple developers on one Sever
On Wed, 2004-12-22 at 13:15 +0100, Henning Meyer wrote:
> I understand this - but I want to use Apache::Registry for
> performance-reasons. How can I get different configurations in different
> Versions of my system?
> Should I use something like Config::Tiny?
> Or can I use Apache::PerlRun just for my config.pl - which I include via
> require 'config.pl';
> ?
There are many ways to do this.
1. Pull the values in with 'do config.pl' instead of require. That will
read the script every time. It will also have a performance penalty
because of this.
2. Put the data in a hash indexed by your application name:
$c{'project_name'} instead of just $c. The project name could be set in
the conf file via PerlSetVar or in your script. Use that name when
writing or reading the config data.
3. Put it in different packages. This is just a variation of #2.
4. Read the config each time using some config thing like Config::Tiny.
This will have a performance hit like #1.
That should give you an idea.
- 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: Apache::DBI and PerlChildExitHandler
On Tue, 2004-12-21 at 09:26 -0500, Joel wrote: > And from what I understand, this is caused when the Apache child exists > and does not execute an explicit $dbh->disconnect() on the database > handle. That is, the connection is not being closed properly before the > handle goes out of scope. That's a reasonable guess. > If this assumption is correct, I think it can be remedied by adding a > PerlChildExitHandler to simply do a $dbh->disconnect() as the child is > exiting. Good idea. Go for it, and if it works send in an Apache::DBI patch. You may have to get a little tricky in order to issue the disconnect, since Apache::DBI is overriding this. > The only nagging thing about this is why hasn't anyone thought of this > and implemented it before? It doesn't result in errors in the apache error_log. - 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: Can Apache::TestMB suppress APXS warnings?
On Tue, 21 Dec 2004, Stas Bekman wrote: > Randy Kobes wrote: > > On Tue, 21 Dec 2004, Geoffrey Young wrote: > > > > > >>>-verbose=0 APXS (/usr/local/apache/bin/apxs) query for SBINDIR failed > >>>APXS (/usr/local/apache/bin/apxs) query for TARGET failed APXS > >>>(/usr/local/apache/bin/apxs) query for SYSCONFDIR failed APXS > >>>(/usr/local/apache/bin/apxs) query for PREFIX failed APXS > >>>(/usr/local/apache/bin/apxs) query for LIBEXECDIR failed APXS > >>>(/usr/local/apache/bin/apxs) query for LIBEXECDIR failed APXS > >>>(/usr/local/apache/bin/apxs) query for LIBEXECDIR failed > >> > >>I'm very surprised the run doesn't abort right here. it > >>probably should if any apxs option was specified, and > >>shouldn't hit this at all of an httpd option is specified. > > > > > > There was a similar problem on Win32 about these warnings, > > related to the unsetting of the PATH environment variable > > for tainting. A fix for this that works for Win32 is in the > > current svn sources - can you try that to see if that helps? > > svn sources of Apache-Test? Joshua is using mp1. so A-T 1.17 should be > pretty good, no? As I guess it turns out, Joshua's problem is unrelated to this problem on Win32 that was fixed in the Apache-Test svn sources. But just for completeness, the problem on Win32 also in principle occurs with mp1; Win32 (and perhaps other platforms in some cases?) need the PATH populated to run apxs. -- best regards, randy -- 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: Apache::DBI and PerlChildExitHandler
Stas Bekman wrote: Also it's possible that using Apache::DBI is the better solution, but it depends on your demands. doh! please ignore me, instead listen to Perrin. Obviously I've missed the big letters saying that you already use Apache::DBI. -- __ 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: compile problems
Barksdale, Ray wrote: Hmm, I managed to get it to work with either -fpic or -fPIC after switching to shared perl. Also built with -m64. I noticed Apache (at least 2.0.52) configures/compiles for -fPIC automagically. But once it loads, it is BIG. (note lotta Apache modules, Apache::Request, CGI loaded via startup.pl). PID Size Share VSize Rss M Elapsed LastReq Srvd Client Virtual Host Request (first 64 chars) 5: 2525 94.4M 88.3M 94.4M 8.8M _ 0.000s 0.000s0 2: 2522 94.4M 88.3M 94.4M 8.8M _ 0.000s 0.000s0 4: 2524 94.4M 88.3M 94.4M 8.8M _ 0.000s 0.000s0 3: 2523 94.4M 88.3M 94.4M 8.8M _ 0.000s 0.000s0 0: 2520 94.4M 88.3M 94.4M 8.8M 1: 2521 108M 97.0M 108M 13.7M W 0.000s 0.000s0 10.1.54.95 testbox2 GET /sys-monitor HTTP/1.1 Total: 608169K ( 580M) size, 145465K ( 139M) approx real size (-shared) wow, that's a lot. Which mpm is that? Must be worker. And if you don't load any modules? -- __ 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: compile problems
> -Original Message- > From: Stas Bekman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 22, 2004 2:28 PM > To: Barksdale, Ray > Cc: Matthew Berk; modperl@perl.apache.org > Subject: Re: compile problems > > > Total: 608169K ( 580M) size, 145465K ( 139M) approx > real size (-shared) > > wow, that's a lot. Which mpm is that? Must be worker. And if > you don't > load any modules? > Prefork. That's what you would think :\ PID Size Share VSize Rss M Elapsed LastReq Srvd Client Virtual Host Request (first 64 chars) 0: 8380 64.9M 62.7M 64.9M 4.3M 3: 8383 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 6: 8386 64.9M 62.7M 64.9M 4.4M _ 0.000s 0.000s0 4: 8384 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 5: 8385 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 2: 8382 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 1: 8381 83.1M 75.5M 83.1M 10.1M W 0.000s 0.000s0 10.1.54.95 testbox2 GET /sys-monitor HTTP/1.1 Total: 495575K ( 473M) size, 101277K (96.6M) approx real size (-shared) > -- > __ > 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 > *CONFIDENTIALITY NOTICE* This e-mail and any files or attachments may contain confidential and privileged information. If you have received this message in error, please notify the sender at the above e-mail address and delete it and all copies from your system. -- 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: compile problems
Barksdale, Ray wrote: Total: 608169K ( 580M) size, 145465K ( 139M) approx real size (-shared) wow, that's a lot. Which mpm is that? Must be worker. And if you don't load any modules? Prefork. That's what you would think :\ PID Size Share VSize Rss M Elapsed LastReq Srvd Client Virtual Host Request (first 64 chars) 0: 8380 64.9M 62.7M 64.9M 4.3M 3: 8383 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 6: 8386 64.9M 62.7M 64.9M 4.4M _ 0.000s 0.000s0 4: 8384 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 5: 8385 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 2: 8382 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 1: 8381 83.1M 75.5M 83.1M 10.1M W 0.000s 0.000s0 10.1.54.95 testbox2 GET /sys-monitor HTTP/1.1 Total: 495575K ( 473M) size, 101277K (96.6M) approx real size (-shared) And if you just start apache w/o loading modperl (you can't still use Apache::VMonitor if you run two instances of Apache, but otherwise you can use top(1). Here (linux kernel 2.6.8) a plain start of Apache+mod_perl gives about 8MB. -- __ 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: compile problems
1 thru 6: without mod_perl 7 thru 12: with mod_perl. Kinda takes you're breath (and ram) away. 1 8738 root 17.1M 15.9M 17.1M 2.0M S httpd 2 8739 nobody 17.1M 15.9M 17.1M 2.0M S httpd 3 8740 nobody 17.1M 15.9M 17.1M 2.0M S httpd 4 8741 nobody 17.1M 15.9M 17.1M 2.0M S httpd 5 8742 nobody 17.1M 15.9M 17.1M 2.0M S httpd 6 8743 nobody 17.1M 15.9M 17.1M 2.0M S httpd 7 8750 root 81.6M 74.5M 81.6M 9.6M S httpd 8 8751 nobody 82.5M 74.5M 82.5M 10.5M R httpd 9 8752 nobody 81.6M 74.5M 81.6M 9.6M S httpd 10 8753 nobody 81.6M 74.5M 81.6M 9.6M S httpd 11 8754 nobody 81.6M 74.5M 81.6M 9.6M S httpd 12 8755 nobody 81.6M 74.5M 81.6M 9.6M S httpd > -Original Message- > From: Stas Bekman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 22, 2004 3:17 PM > To: Barksdale, Ray > Cc: modperl@perl.apache.org > Subject: Re: compile problems > > Barksdale, Ray wrote: > > >>>Total: 608169K ( 580M) size, 145465K ( 139M) approx > >> > >>real size (-shared) > >> > >>wow, that's a lot. Which mpm is that? Must be worker. And if > >>you don't > >>load any modules? > >> > > > > > > Prefork. That's what you would think :\ > > > > PID Size Share VSize Rss M Elapsed LastReq Srvd > Client Virtual > > Host Request (first 64 chars) > > 0: 8380 64.9M 62.7M 64.9M 4.3M > > > > 3: 8383 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 > > > > 6: 8386 64.9M 62.7M 64.9M 4.4M _ 0.000s 0.000s0 > > > > 4: 8384 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 > > > > 5: 8385 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 > > > > 2: 8382 64.9M 62.7M 64.9M 4.3M _ 0.000s 0.000s0 > > > > 1: 8381 83.1M 75.5M 83.1M 10.1M W 0.000s 0.000s0 > 10.1.54.95 testbox2 > > GET /sys-monitor HTTP/1.1 > > > > Total: 495575K ( 473M) size, 101277K (96.6M) approx > real size (-shared) > > And if you just start apache w/o loading modperl (you can't still use > Apache::VMonitor if you run two instances of Apache, but > otherwise you can > use top(1). > > Here (linux kernel 2.6.8) a plain start of Apache+mod_perl > gives about 8MB. > > > -- > __ > 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 > *CONFIDENTIALITY NOTICE* This e-mail and any files or attachments may contain confidential and privileged information. If you have received this message in error, please notify the sender at the above e-mail address and delete it and all copies from your system. -- 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: compile problems
Barksdale, Ray wrote: 1 thru 6: without mod_perl 7 thru 12: with mod_perl. Kinda takes you're breath (and ram) away. 1 8738 root 17.1M 15.9M 17.1M 2.0M S httpd 2 8739 nobody 17.1M 15.9M 17.1M 2.0M S httpd 3 8740 nobody 17.1M 15.9M 17.1M 2.0M S httpd 4 8741 nobody 17.1M 15.9M 17.1M 2.0M S httpd 5 8742 nobody 17.1M 15.9M 17.1M 2.0M S httpd 6 8743 nobody 17.1M 15.9M 17.1M 2.0M S httpd 7 8750 root 81.6M 74.5M 81.6M 9.6M S httpd 8 8751 nobody 82.5M 74.5M 82.5M 10.5M R httpd 9 8752 nobody 81.6M 74.5M 81.6M 9.6M S httpd 10 8753 nobody 81.6M 74.5M 81.6M 9.6M S httpd 11 8754 nobody 81.6M 74.5M 81.6M 9.6M S httpd 12 8755 nobody 81.6M 74.5M 81.6M 9.6M S httpd something is very wrong then. On linux I get: Apache w/o modperl stas 8315 0.9 0.3 5792 2596 ?Ss 17:14 0:00 httpd stas 8317 0.0 0.3 5792 2700 ?S17:14 0:00 httpd Apache w/ modperl and Apache::Request(Rec|IO). stas 8362 0.3 0.6 9556 5248 ?Ss 17:15 0:00 httpd stas 8367 0.0 0.6 9556 5360 ?S17:15 0:00 httpd Apache w/ modperl and ModPerl::MethodLookup::preload_all_modules(); stas 8446 2.4 0.9 11464 7140 ?Ss 17:18 0:00 httpd stas 8447 0.0 0.9 11464 7252 ?S17:18 0:00 httpd Also remember that this build is full of debugging options enabled. The actual non-debug Apache w/ and w/o modperl should be much smaller. Could it be a compile thingy that went wrong? But I'm not surprised - your Apache eats more than 3 times more RAM than here on linux (of course we didn't compare what Apache modules you and I have loaded, but still it's a *big* difference). So it's really your OS/compiler issue. There is no reason why Apache on its own should be so big. -- __ 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
CGI apps receiving incomplete POST parameters
I've recently converted from Apache 1.3.x to Apache 2.0/mod_perl 1.99 on RedHat 9. The issue I'm having are for those applications that attempt to POST data (e.g. from a form) that are, for the most part, pretty large (e.g. 46kB). Unfortunately, with this newer version, the applications aren't receiving the full POST'd parameters. To best describe what I'm talking about, here are two examples. For each one, you'll see some version information along with a form that have 500 pre-checked boxes. (each has large value names to help increase the POST size). To test this, go to the very end of the form and click 'Submit Query'. Working (Apache 1.3.x using mod_perl 1.26): https://www.globaldataguard.net/perl/mycheckbox.cgi Broken (Apache 2.0.40 using mod_perl 1.99): https://www.globaldataguard.net:5043/perl/mycheckbox.cgi Each version will attempt to print out their entire parameter list using CGi.pm's Dump() subroutine. The "working" version will print out a complete paramter list, whereas the "broken" version arbitrarily lops off the data. To ensure that it wasn't some odd code behavior or even the web server, I took the same mycheckbox.cgi code and reconfigured the webserver to use mod_cgi (instead of mod_perl). When I do this, all works as intended (except for it not being under mod_perl of course). Thank you, Kurt signature.asc Description: This is a digitally signed message part
RE: compile problems
> -Original Message- > From: Stas Bekman [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 22, 2004 4:23 PM > To: Barksdale, Ray > Cc: modperl@perl.apache.org > Subject: Re: compile problems > > something is very wrong then. On linux I get: > > Apache w/o modperl > stas 8315 0.9 0.3 5792 2596 ?Ss 17:14 0:00 httpd > stas 8317 0.0 0.3 5792 2700 ?S17:14 0:00 httpd > > Apache w/ modperl and Apache::Request(Rec|IO). > stas 8362 0.3 0.6 9556 5248 ?Ss 17:15 0:00 httpd > stas 8367 0.0 0.6 9556 5360 ?S17:15 0:00 httpd > > Apache w/ modperl and ModPerl::MethodLookup::preload_all_modules(); > stas 8446 2.4 0.9 11464 7140 ?Ss 17:18 0:00 httpd > stas 8447 0.0 0.9 11464 7252 ?S17:18 0:00 httpd > > Also remember that this build is full of debugging options > enabled. The > actual non-debug Apache w/ and w/o modperl should be much smaller. > > Could it be a compile thingy that went wrong? But I'm not > surprised - your > Apache eats more than 3 times more RAM than here on linux (of > course we > didn't compare what Apache modules you and I have loaded, but > still it's a > *big* difference). So it's really your OS/compiler issue. There is no > reason why Apache on its own should be so big. > I agree it should be much smaller. From your reply I seem to have given the impression I was running on something other than Linux. Sorry about that. We run Redhat's Fedora Core 2 Linux on x86 (32-bit) for prod/testing. This was our first try at 64-bit (Redhat Fedora Core 2 AMD64). I'll check how that compares to what you've shared. Maybe I'll trip over the problem since I built the 64-bit stuff using the same procedure. Ok. I couldn't wait. My numbers on 32-bit linux are almost identical (+/- 2%) to yours. When I get some more time I'll dig into the 64-bit stuff and see what I'm doing wrong. On the bright side everything runs perfectly (in a bloated sort of way ;) Thanx a load. *CONFIDENTIALITY NOTICE* This e-mail and any files or attachments may contain confidential and privileged information. If you have received this message in error, please notify the sender at the above e-mail address and delete it and all copies from your system. -- 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: compile problems
Barksdale, Ray wrote: I agree it should be much smaller. From your reply I seem to have given the impression I was running on something other than Linux. Sorry about that. We run Redhat's Fedora Core 2 Linux on x86 (32-bit) for prod/testing. This was our first try at 64-bit (Redhat Fedora Core 2 AMD64). I'll check how that compares to what you've shared. Maybe I'll trip over the problem since I built the 64-bit stuff using the same procedure. Ok. I couldn't wait. My numbers on 32-bit linux are almost identical (+/- 2%) to yours. When I get some more time I'll dig into the 64-bit stuff and see what I'm doing wrong. OK, so it has something to do with 64-bit-ness. But I didn't understand. Was this problem seen on a 64-bit CPU or on a 32-bit CPU, but then code was compiled for 64-bit? On the bright side everything runs perfectly (in a bloated sort of way ;) Thanx a load. I didn't do anything :) -- __ 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: CGI apps receiving incomplete POST parameters
Kurt Newman wrote: I've recently converted from Apache 1.3.x to Apache 2.0/mod_perl 1.99 on RedHat 9. Kurt, there is no mp1.99. There is 1.99_xx. that xx has a very big significance, since many problems were fixed between 1.99_01 and 1.99_18. 1) Please upgrade to the latest mp2 version, which is: 1.99_18 (aka 2.0.0-RC1) http://perl.apache.org/download/index.html 2) If the problem persists, please read how a proper bug report should be submitted: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems 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: CGI apps receiving incomplete POST parameters
What would happen if you extended the time out period of the server? Jay Scherrer On Wednesday 22 December 2004 03:04 pm, Kurt Newman wrote: > I've recently converted from Apache 1.3.x to Apache 2.0/mod_perl > 1.99 on RedHat 9. > > The issue I'm having are for those applications that attempt to > POST data (e.g. from a form) that are, for the most part, pretty > large (e.g. 46kB). Unfortunately, with this newer version, the > applications aren't receiving the full POST'd parameters. > > To best describe what I'm talking about, here are two examples. > For each one, you'll see some version information along with a form > that have 500 pre-checked boxes. (each has large value names to > help increase the POST size). To test this, go to the very end of > the form and click 'Submit Query'. > > Working (Apache 1.3.x using mod_perl 1.26): > https://www.globaldataguard.net/perl/mycheckbox.cgi > > Broken (Apache 2.0.40 using mod_perl 1.99): > https://www.globaldataguard.net:5043/perl/mycheckbox.cgi > > Each version will attempt to print out their entire parameter list > using CGi.pm's Dump() subroutine. The "working" version will print > out a complete paramter list, whereas the "broken" version > arbitrarily lops off the data. > > To ensure that it wasn't some odd code behavior or even the web > server, I took the same mycheckbox.cgi code and reconfigured the > webserver to use mod_cgi (instead of mod_perl). When I do this, > all works as intended (except for it not being under mod_perl of > course). > > Thank you, > Kurt -- 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
