[RFC] Do Not Run Everything on One mod_perl Server
Let's assume that you have two different sets of scripts/code which have a little or nothing in common at all (different modules, no base code sharing), the basic mod_perl process before the code have been loaded of three Mbytes and each code base adds ten Mbytes when loaded. Which makes each process 23Mb in size when all the code gets loaded. Assuming that we have 230 Mb of RAM available to the mod_perl server, the memory limitation allows us to run ten mod_perl servers (23Mb*10=230Mb). Now consider this practical decision. Since we have recognized that the code sets are very distinct in nature and there is no significant memory sharing in place, the wise thing to do is to split the two code sets between two mod_perl servers (a single mod_perl server actually is a set of the parent process and a number of the child processes). So instead of running everything on one server, now we move the second code set onto another mod_perl server. At this point we are talking about a single machine. Let's look at the figures again. After the split we will have five servers of 13Mb and another five servers of 13Mb. A total of 130Mb memory required. But, hey, we have 230Mb of memory. We've got 100Mb memory freed up. So we can run about eight more servers using the same memory size. We have almost doubled the number of servers without changing machine's hardware (13Mb*18=234Mb). Moreover this new setup allows us to fine tune the two code sets, since in reality the smaller in size code base might have a higher hit rate, so we can benefit even more. Let's assume that based on the usage statistics we know that the first code set deployed in 70% of requests and the other 30% are used by the second set. Now we assume that the first code set requires only 6Mbytes of RAM over the basic mod_perl server size, and the second set needs 14Mbytes (we try to make the comparisons against the same original setup where there were ten processes of 23Mbytes in size each). So now the first mod_perl server running the first code set will have all its processes of 9Mbytes in size (3Mb+6Mb), and the second of 17Mb (3Mb+14Mb). Given that we have a 70:30 hits relation and that we have 230Mbytes of available memory, we have to solve this equation: 0.7*X * 9 + 0.3*X * 17 = 230 where X is the total number of the processes that can be run using the 230Mbytes of available memory, and 0.7 and 0.3 reflect the 70:30 hits relation, 9 and 17 are the respective sizes of the two servers and with their code sets in use. When we solve this simple equation, we get that X equals 20 and therefore, we need 14 processes for the first code set and 6 processes for the second. If we compare this findings with the initial setup we have doubled the number of the servers from 10 to 20. The hits rate optimized solution allowed us to run two more servers in total and gave us five more servers (14 versus 9) for the most wanted code base, relative to the simple 50:50 split as in the first example. Of course if you can identify more than two distinct sets of code and your hits rate statistics may require more complicated decisions. You ought to make even more splits and run three and more mod_perl servers. Remember that having too many running processes doesn't necessarily means a better performance because of all of them will fight over CPU time slices. The more processes are running the less CPU time each gets the slower the overall performance will be. Therefore after hitting a certain load you might want to start spreading servers over different machine. __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
RE: Modperl/Apache deficiencies... Memory usage.
I understand that. :) And that was something that I had to learn myself. :) It's a BAD thing when suddenly your httpd process takes up 100 MB. :) It's just that it sounded like Shane was saying that his httpds were starting OUT at 4 to 6 MB. That sounded a little unusual to me but then again, I've pared down my httpd config so that I don't have things in that I don't need. I'm just curious as to what he has in there. -- Jeff Stuart [EMAIL PROTECTED] -Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 18, 2000 1:24 AM To: [EMAIL PROTECTED] Subject: RE: Modperl/Apache deficiencies... Memory usage. If you aren't careful with your programming, an apache HTTPD can always grow pretty quickly because Perl never releases the RAM it allocates previously. While it does that reference count garbage collection, that is internal to the RAM that was allocated. Let's say you need to sort a record set returned from a DBI call in an unusual perl-like way. If you do this "in memory", you need an array to hold the entire recordset in memory at once. If you do this, though, you will allocate the RAM for that one request that sorted the array and then the HTTPD will remain that size forever. Keeping the higher RAM allocation is good for performance if you have the RAM of course. So this is one of those design tradeoffs. And Perl was not really written to be a persistent language, so again, the tradeoff of operational speed seems to make sense versus persistent memory usage. Later, Gunther At 12:25 AM 4/18/00 -0400, Jeff Stuart wrote: >Shane, question for you. No offense intended here at all but what do you >have in your apache servers (other than mod_perl) that use 4 to 6 MB? I've >got one server that I'm working on that handles close 1 Mil hits per day >than runs WITH mod_perl that uses 4 to 6 MB. ;-) Without mod_perl, it >takes up around 500 to 800 KB. Now on another server my mod_perl server >uses about 13 Mb per but it's my devel machine so I've got a lot of stuff >loaded that I wouldn't have in a production server. > >-- >Jeff Stuart >[EMAIL PROTECTED] > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Saturday, April 15, 2000 6:46 PM >To: Perrin Harkins >Cc: [EMAIL PROTECTED] >Subject: Re: Modperl/Apache deficiencies... Memory usage. > >Your apache processes would be the size of a stock >apache process, like 4-6M or so, and you would have 1 process that >would be 25MB or so that would have all your registry in it. __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: Modperl/Apache deficiencies... Memory usage.
> [ By the way, Stas - is there a CVS version of the guide that I can make > patches against? I found a few inaccuracies. ] Yeah, but it's not accessible for people from the outside. I think I'll start using the same mechanism apache.org does -- rolling out CVS snapshots every few hours. At this time I'll send you the latest snapshot on request. I hope that when we get the sourcegarden eventually running, I'll move it there. Or to the apache site, but I don't know where should it fit there, since I work with the pod files and release the processed html/pdf files about once a month. Since the project is very big and requires extra work on each release I don't update the online version with the same frequency the sources are updated. __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
RE: Modperl/Apache deficiencies... Memory usage.
If you aren't careful with your programming, an apache HTTPD can always grow pretty quickly because Perl never releases the RAM it allocates previously. While it does that reference count garbage collection, that is internal to the RAM that was allocated. Let's say you need to sort a record set returned from a DBI call in an unusual perl-like way. If you do this "in memory", you need an array to hold the entire recordset in memory at once. If you do this, though, you will allocate the RAM for that one request that sorted the array and then the HTTPD will remain that size forever. Keeping the higher RAM allocation is good for performance if you have the RAM of course. So this is one of those design tradeoffs. And Perl was not really written to be a persistent language, so again, the tradeoff of operational speed seems to make sense versus persistent memory usage. Later, Gunther At 12:25 AM 4/18/00 -0400, Jeff Stuart wrote: >Shane, question for you. No offense intended here at all but what do you >have in your apache servers (other than mod_perl) that use 4 to 6 MB? I've >got one server that I'm working on that handles close 1 Mil hits per day >than runs WITH mod_perl that uses 4 to 6 MB. ;-) Without mod_perl, it >takes up around 500 to 800 KB. Now on another server my mod_perl server >uses about 13 Mb per but it's my devel machine so I've got a lot of stuff >loaded that I wouldn't have in a production server. > >-- >Jeff Stuart >[EMAIL PROTECTED] > >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Saturday, April 15, 2000 6:46 PM >To: Perrin Harkins >Cc: [EMAIL PROTECTED] >Subject: Re: Modperl/Apache deficiencies... Memory usage. > >Your apache processes would be the size of a stock >apache process, like 4-6M or so, and you would have 1 process that >would be 25MB or so that would have all your registry in it. __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
RE: Modperl/Apache deficiencies... Memory usage.
Shane, question for you. No offense intended here at all but what do you have in your apache servers (other than mod_perl) that use 4 to 6 MB? I've got one server that I'm working on that handles close 1 Mil hits per day than runs WITH mod_perl that uses 4 to 6 MB. ;-) Without mod_perl, it takes up around 500 to 800 KB. Now on another server my mod_perl server uses about 13 Mb per but it's my devel machine so I've got a lot of stuff loaded that I wouldn't have in a production server. -- Jeff Stuart [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Saturday, April 15, 2000 6:46 PM To: Perrin Harkins Cc: [EMAIL PROTECTED] Subject: Re: Modperl/Apache deficiencies... Memory usage. Your apache processes would be the size of a stock apache process, like 4-6M or so, and you would have 1 process that would be 25MB or so that would have all your registry in it.
RE: Compiler errors...
Title: RE: Compiler errors...
Well this does work better, but as I found out, it doesn't solve my problem. While this does catch runtime errors, it doesn't catch compile-time errors when using Apache::StatINC.
However thanks to your hint on how to do this, I was able to patch Apache::StatINC to display the compile-time errors for me.
In Apache::StatINC:
I replaced:
require $key;
With:
eval {
require $key;
};
if ($@ && $DEBUG) {
$r->content_type('text/html');
$r->send_http_header();
$r->print("Perl Compiler Errors:");
$r->print($@);
$r->print("");
}
With this, and the eval{} wrapper around the regular PerlHandler (below), I've got all error messages displaying to the browser (I think :-)
Of course, there is still the issue of non-fatal warning messages not being displayed to the browser. However, unless someone has an idea how to do that, I'll live without it.
Thanks for the help...
-Robert
-Original Message-
From: Ken Y. Clark [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 14, 2000 8:40 PM
To: modperl (E-mail)
Subject: Re: Compiler errors...
On Fri, 14 Apr 2000, Robert Jenks wrote:
> We are currently using Linux/Apache/mod_perl (and Stat::INC) with good
> success (thanks to the help of this list) as a replacement for
> WinNT/IIS/Velocigen. Everything is (now) going good except that we miss one
> of Velocigen's debugging features. Velocigen would display compiler errors
> to the browser (after a file-change recompile).
>
> I'm currently using CGI::Carp qw(fatalsToBrowser), but this only shows
> runtime errors.
>
> Is there a way to do this? I've thought about using the Apache
> "ErrorDocument" config to call a perl script which would display the last
> few lines of the error_log, but it wouldn't be very elegant.
robert,
i would suggest wrapping all the meat of you code in an eval, and then
checking for errors on exit. when things go wrong, you handle the error.
when things are fine, you create output, like so:
package Foo::Bar;
use Apache;
use Apache::Constants qw(:common);
use strict;
sub handler {
my $r = shift;
eval {
# put anything here that could possibly error out
# like database connections, file reads, etc.
};
$r->content_type('text/html');
$r->send_http_header;
if ($@) {
$r->print("There was an error: '$@'");
} else {
$r->print('Apache/mod_perl rules!');
}
return OK;
}
1;
hth,
ky
Re: Modperl/Apache deficiencies... Memory usage.
While I agree that a true garbage collector would be cool. I wonder what the utility would really be when you would primarily want it in mod_perl type stuff. Yet, mod_perl is also great because of speed. One of the nice things about Perl right now is that it is fast and that is partially due to the reference counting instead of running garbage collection algorithms. In addition, generally for those where speed is a huge huge concern, RAM and h/w is cheap relative to those concerns. So I am not sure how worth it, it really would be in the end. Likely it would also require quite a bit of Perl internals mucking about, so a g-coll routine would take a long time to debug and the bugs themselves would be subtle and extremely difficult to track down. So I would not see a lot of people being interested in testing something that is hard to debug down for a benefit that no one has really cried out for (until now?). Anyway, I'm sorry to naysay this because I think a new garbage collection model would be interesting, but I am just wondering about the utility of it in the end (versus improving other parts of Perl/mod_perl). eg the idea that I think you proposed last week to have a detached Perl process with multiple Perl objects (with threaded access to them) attached to apache servers via socket or IPC communication would have more practical uses that I could see and would be easier to get out than a new garbage collection algorithm. Later, Gunther
Re: mod_perl with jpl
I am not going to answer your question directly because I don't know the answer. However, consider that not many people use jpl. Therefore, it is likely that it has more bugs than other parts of Perl. Also consider that the software you use may end up disliking the process model and rely on in-memory sharing (since java is multi-threaded, this assumption is made a lot -- especially for caching) so the model of Apache/mod_perl may not marry well. Given these assumptions (which may not be entirely true in your situation... YMMV), your better bet may be to set up a Java server that communicates with your 3rd party Java libraries and then call the server from mod_perl using an RPC mechanism. Since it sounds like you want to get up and running quickly, I recommend prototyping with a few select procedures you want to call manually... But for production, you could consider CORBA (I wouldn't unless it's a huge well defined interface) or SOAP (or some other XML-RPC mechanism) -- I tend to like these better as they are easier to troubleshoot for mere mortals than IIOP/CORBA. Mixing languages is a bit like mixing drugs... Not that I would know of course. Although I do think Perl and Java are both addictive substances. Later, Gunther At 02:59 PM 4/17/00 -0400, Paul G. Weiss wrote: >I have a requirement to make use of some third party software >written in Java. I would like to get my mod_perl based scripts >to talk to this software. To that end I am interested in the >jpl shipped with 5.6. Has anyone successfully integrated this >with mod_perl on Solaris? If so, how did you build Perl. I >am particularly interested in the threading options. > >More generally, how do the threading options in Perl influence >mod_perl? Does mod_perl simply ignore them, being process based? >Is it ill-advise to enable threading when you will be using >mod_perl? > >-P
Re: Modperl/Apache deficiencies... Memory usage.
[EMAIL PROTECTED] wrote:
>On Mon, Apr 17, 2000 at 01:33:08PM -0600, Jason Terry wrote:
>> This is the first i have seen "delete" referenced. What does it do?
>> How is it used?
>>
>> Thank you
>> -Jason
>
>It's the stack cleaner... but it only works for scalars, and maybe
>arrays, but its better for arrays and hashes to do the following at
>the bottom of each code block in registry scripts. (True good note)
>
>@somearray = ();
>%somehash =();
>delete $somescalar;
>(and don't forget untie :-> )
>
>Basically it will clean up *most* of the memory taken up by these
>variables.
There are some serious misconceptions at work here. First of all, delete()
can't be used on a scalar. I think you're thinking of undef(). And second,
the memory de-allocation is very good, and very precise, and doesn't work any
differently under mod_perl than it does under regular Perl. Why? Because
mod_perl *IS* regular Perl. It's simply a Perl interpreter that lasts a long
time.
Code run under Apache::Registry has some additional things it needs to
consider, since the entire "CGI" will be wrapped up inside a subroutine,
creating trapped lexicals (the guide is actually incorrect in calling them
closures). But the guide suggests several workarounds, all of which will get
the job done.
[ By the way, Stas - is there a CVS version of the guide that I can make
patches against? I found a few inaccuracies. ]
Well-written code will get its variables cleaned up exactly when and how it
wants it cleaned up. This is true under mod_perl or standalone Perl.
Sometimes you have to be a little more careful under mod_perl, especially using
Registry, because of the persistence & subroutine-wrapping issues. But try
this [simplified] version of one of your examples:
my $i=0;
dosomefunnierstuff($i);
sub dosomefunnierstuff {
print "Funnierstuff is ", $_[0]++, "\n";
}
Most good coders would argue that functions that access variables that
aren't explicitly passed to them are best avoided anyway. This is just
another reason that's true (or another version of the same reasons).
Of course, since the strange behavior you observed is fully expected
once you understand the problem, slick (and disliked =) coders can feel
free to take advantage of it for their own evil purposes.
------
Ken Williams Last Bastion of Euclidity
[EMAIL PROTECTED]The Math Forum
Re: Help needed with Apache::AuthCookie 2.007
[EMAIL PROTECTED] (Kenneth Frankel) wrote: >Could someone provide a good FAQ or example of how to impliment this >thing? The package documentation's "just copy the test script" example I'm >sure is a great time-saver for the author but when one has problems it's >really a pain with all the unrelated testing code. It's not a time-saver for me - the module is fully documented (344 lines of docs), AND there's a test suite. If you find that some information is missing from the documentation, please tell me. The docs never advise to "just copy" anything, they merely point out that the test suite is often a useful place to find code that works. Everything should also be fully documented. Simply copying the example is actually a *bad* idea since it'll probably mean one won't really understand how things work. Not good for an auth system. >I'm having problems and it's probably my mod-perl configuration but I >can't sort out what's wrong comparing to the test-script non-example. >If someone could provide their setup without the "WhatEver" and >"Sample" namings it'd be really appreciated! What difference would that make? But if you want it, I'll mail you mine off-list. >Thanks, >Kenneth > >P.S. If you need to fix what's wrong (thanks, man!), the errors are >configuration error: couldn't check user. No user file?: /bqbin/gui.pl That error isn't coming from Apache::AuthCookie, it's coming from Apache (or its basic auth module). For one reason or another, you still seem to be configured for basic auth. Are you sure you have the AuthType and AuthName parameters set correctly? ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Apache::ASP problem, example index.html not working
- Original Message - From: Andy Yiu <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, April 15, 2000 1:13 PM Subject: RE: Apache::ASP problem, example index.html not working > Hi, this is Andy again. > > It's about that, after I installed the ASP patch, all > other *.asp are working but the index.html is not > which claim that it couldn't find glocal.asa > > The .htaccess file I used is from your example folder, > which is : > > > Debug Output > > > RUN ASP (v0.18) for /data/home/asp/eg/index.html > > GlobalASA package Apache::ASP::Demo > > ASP object created - GlobalASA: > Apache::ASP::GlobalASA=HASH(0x83c5370); Request: > Apache::ASP::Request=HASH(0x83947d0); Response: > Apache::ASP::Response=HASH(0x83946d4); Server: > Apache::ASP::Server=HASH(0x83945a8); basename: > index.html; compile_includes: 1; dbg: 2; > debugs_output: ARRAY(0x82834c0); filename: > /data/home/asp/eg/index.html; global: /tmp; > global_package: Apache::ASP::Demo; id: NoCache; > includes_dir: ; init_packages: ARRAY(0x8302fe4); > no_cache: 1; no_state: 1; package: Apache::ASP::Demo; > pod_comments: 1; r: Apache=SCALAR(0x840ca70); > sig_warn: ; stat_inc: ; stat_inc_match: ; > stat_scripts: 1; unique_packages: ; use_strict: ; > > parsing index.html > > runtime exec of dynamic include header.inc args () > > parsing header.inc > > undefing sub Apache::ASP::Demo::_tmp_header_inc code > CODE(0x840ff20) > > compile include header.inc sub _tmp_header_inc > > runtime exec of dynamic include footer.inc args () > > parsing footer.inc > > already failed to load Apache::Symbol Check that both Apache::Symbol and and Devel::Symdump are installed and are in the lib path. I had a similar problem when I first installed Apache::ASP. My Apache::Symbol was installed but, Devel::Symdump (required by Apache::Symbol, not Apache::Symdump) was not, hence Apache::Symbol::undef did not load. After I installed Devel::Symdump everything worked. -dmitri
perl job opportunities
As these jobs involve perl programming, I thought you may have an interest in the following jobs for developing database-driven web sites at Forum One Communications. Please see www.forumone.com/consult/ for details. SENIOR WEB PROGRAMMER 6+ yrs exp. Unix/CGI programming, with 2+ yrs developing dynamic database web sites in Perl w/ at least 2 of JavaScript, Java, DHTML, SSI, PHP, mySQL. WEB DEVELOPER 1-2 yrs. proven exp. in basic html web dev. -- David Hobbs
Re: Modperl/Apache deficiencies... Memory usage.
You're right. I am mistaken :-(. Just tested it, and it was
something silly in an old script I had lying around that I thought was
a bug... my mistake. (Note to self: Test all examples before
posting... or you look like an idiot :-) )
Sorry,
Shane.
> I think you're mistaken. Try the following:
>
> package My::Test;
>
> sub new {
> return bless {}, shift;
> }
> sub DESTROY {
> warn "destroyed";
> }
> sub test {
> my $object = new My::Test;
> print ref $object, "\n";
> # object will get destroyed when it goes out of scope (now)
> }
>
> for (1..10) {
> warn "t $_\n";
> test();
> }
>
> __END__
>
> Your second example doesn't do what I think you were expecting.
>
> Jim
Re: Modperl/Apache deficiencies... Memory usage.
>This is the first i have seen "delete" referenced. What does it do? >How >is it used? Well, you should read the manuyal, or "Programming Perl" for the real answer. Or, were you speaking in reference to delete() specifically under mod_perl? In either case, delete() removes the specified key => value pair from a hash, but cannot be used to delete "regular" variables, such as a plain scalar. For those, or for an entire hash, you should use undef(). Jason Simms __ Get Your Private, Free Email at http://www.hotmail.com
Re: Modperl/Apache deficiencies... Memory usage.
[EMAIL PROTECTED] wrote:
> my $i=0;
> dosomefunnierstuff();
> sub dosomefunnierstuff {
> my $funnierstuff;
> if($funnierstuff=~/funnier/) {
> dosomefunnierstuff();
> } else {
> $funnierstuff="funnier".$i++;
> }
> print "Funnierstuff is $funnierstuff\n";
> }
>
> That proves the point a bit more clearly. It will show that each
> layer of the "stack" keeps its own discreet copy of the variable.
Oh, I see what you're talking about. That's a closure. It's a language
feature, so changing that behavior would be significant. This shouldn't
be a problem if you simply avoid using closures in a recursive
algorithm. In your example, I believe only the value of $i will be
saved each time, since $funnierstuff will go out of scope at the end of
the block and get garbage collected.
- Perrin
Re: Modperl/Apache deficiencies... Memory usage.
On Tue, 18 Apr 2000 [EMAIL PROTECTED] wrote: > Go out of scope, yes. Destroyed, no. Want to test? No problem. Do > the following in a perl script. > > my($funnything); > print"Value of funnything is $funnything"; > $funnything="Uh oh... check this out"; This only happens with Apache::Registry and is documented in the guide. If you were to do that inside a handler it would work just fine. The Apache::Registry problem is a side effect of the magic that goes into making it work, but is not surprising and is the expected behavior. If performance and memory are a concern you should probably prefer handlers anyway. -dave /*== www.urth.org We await the New Sun ==*/
Re: Modperl/Apache deficiencies... Memory usage.
On Mon, Apr 17, 2000 at 01:33:08PM -0600, Jason Terry wrote: > This is the first i have seen "delete" referenced. What does it do? How is it used? > > Thank you > -Jason It's the stack cleaner... but it only works for scalars, and maybe arrays, but its better for arrays and hashes to do the following at the bottom of each code block in registry scripts. (True good note) @somearray = (); %somehash =(); delete $somescalar; (and don't forget untie :-> ) Basically it will clean up *most* of the memory taken up by these variables. Thanks, Shane.
Re: Modperl/Apache deficiencies... Memory usage.
I get it. You're talking about Apache::Registry scripts. http://perl.apache.org/guide/perl.html#my_Scoped_Variable_in_Nested_S Jim
Re: Modperl/Apache deficiencies... Memory usage.
This is the first i have seen "delete" referenced. What does it do? How is it used?
Thank you
-Jason
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 17, 2000 9:32 PM
Subject: Re: Modperl/Apache deficiencies... Memory usage.
> >
> > Go out of scope, yes. Destroyed, no. Want to test? No problem. Do
> > the following in a perl script.
> >
> > my($funnything);
> > print"Value of funnything is $funnything";
> > $funnything="Uh oh... check this out";
> >
> > You'll find some interesting results on your second interation :-).
> > Even funnier might be the folowing...
> >
> > dosomefunnystuff();
> > sub dosomefunnystuff {
> > my($funnystuff);
> > if($funnystuff eq "funny") {
> > dosomefunnystuff();
> > }
> > print "Funnystuff is $funnystuff";
> > $funnystuff="funny";
> > }
> >
> > Try that, and you will truely find out how memory inefficient modperl
> > is :-). I haven't tested that second one, but based on what I know
> > about how perl works... it should prove... interesting.
> >
> > Thanks,
> > Shane.
>
> Quick note about this: You'll have to hit the same process, so you
> might have to reload a couple times for the effect to hit. Also
> something maybe even funner...
> my $i=0;
> dosomefunnierstuff();
> sub dosomefunnierstuff {
> my $funnierstuff;
> if($funnierstuff=~/funnier/) {
> dosomefunnierstuff();
> } else {
> $funnierstuff="funnier".$i++;
> }
> print "Funnierstuff is $funnierstuff\n";
> }
>
> That proves the point a bit more clearly. It will show that each
> layer of the "stack" keeps its own discreet copy of the variable.
> That's why I've said before recursion!=good for modperl.
> Personally... I LOVE recursive algorithms... but it just doesn't make
> sense in a mod_perl enviro. If you do use recursion and have large
> variables of strings for instance... you should pass by reference when
> possible.., and you use "delete" at the bottom of the code block when
> possible.
>
> Thanks,
> Shane.
>
> >
> > >
> > > - Perrin
Re: Modperl/Apache deficiencies... Memory usage.
>
> Go out of scope, yes. Destroyed, no. Want to test? No problem. Do
> the following in a perl script.
>
> my($funnything);
> print"Value of funnything is $funnything";
> $funnything="Uh oh... check this out";
>
> You'll find some interesting results on your second interation :-).
> Even funnier might be the folowing...
>
> dosomefunnystuff();
> sub dosomefunnystuff {
> my($funnystuff);
> if($funnystuff eq "funny") {
> dosomefunnystuff();
> }
> print "Funnystuff is $funnystuff";
> $funnystuff="funny";
> }
>
> Try that, and you will truely find out how memory inefficient modperl
> is :-). I haven't tested that second one, but based on what I know
> about how perl works... it should prove... interesting.
>
> Thanks,
> Shane.
Quick note about this: You'll have to hit the same process, so you
might have to reload a couple times for the effect to hit. Also
something maybe even funner...
my $i=0;
dosomefunnierstuff();
sub dosomefunnierstuff {
my $funnierstuff;
if($funnierstuff=~/funnier/) {
dosomefunnierstuff();
} else {
$funnierstuff="funnier".$i++;
}
print "Funnierstuff is $funnierstuff\n";
}
That proves the point a bit more clearly. It will show that each
layer of the "stack" keeps its own discreet copy of the variable.
That's why I've said before recursion!=good for modperl.
Personally... I LOVE recursive algorithms... but it just doesn't make
sense in a mod_perl enviro. If you do use recursion and have large
variables of strings for instance... you should pass by reference when
possible.., and you use "delete" at the bottom of the code block when
possible.
Thanks,
Shane.
>
> >
> > - Perrin
Re: Modperl/Apache deficiencies... Memory usage.
On Apr 18, [EMAIL PROTECTED] wrote:
> On Mon, Apr 17, 2000 at 11:12:24AM -0700, Perrin Harkins wrote:
> > [EMAIL PROTECTED] wrote:
> > > Now with modperl the Perl garbage collector is
> > > NEVER used. Because the reference count of those variables is never
> > > decremented... it's because it's all in the registry, and it's hard to
> > > tell... hmm... what should I throw away, and what should I keep? ;-).
> >
> > What I know about Perl internals could fit on the head of a pin, but
> > this strikes me as a very odd statement. If the garbage collector is
> > never used, why do my lexical variables go out of scope and get
> > destroyed? There are mod_perl packages like Apache::Session that
> > absolutely depend on garbage collection of lexical variables to work.
> > Are you saying that destroying the variables and actually reclaiming the
> > memory are separate, and only the first is happening?
>
> Go out of scope, yes. Destroyed, no. Want to test? No problem. Do
> the following in a perl script.
I think you're mistaken. Try the following:
package My::Test;
sub new {
return bless {}, shift;
}
sub DESTROY {
warn "destroyed";
}
sub test {
my $object = new My::Test;
print ref $object, "\n";
# object will get destroyed when it goes out of scope (now)
}
for (1..10) {
warn "t $_\n";
test();
}
__END__
Your second example doesn't do what I think you were expecting.
Jim
Re: Modperl/Apache deficiencies... Memory usage.
On Mon, Apr 17, 2000 at 11:12:24AM -0700, Perrin Harkins wrote:
> [EMAIL PROTECTED] wrote:
> > Now with modperl the Perl garbage collector is
> > NEVER used. Because the reference count of those variables is never
> > decremented... it's because it's all in the registry, and it's hard to
> > tell... hmm... what should I throw away, and what should I keep? ;-).
>
> What I know about Perl internals could fit on the head of a pin, but
> this strikes me as a very odd statement. If the garbage collector is
> never used, why do my lexical variables go out of scope and get
> destroyed? There are mod_perl packages like Apache::Session that
> absolutely depend on garbage collection of lexical variables to work.
> Are you saying that destroying the variables and actually reclaiming the
> memory are separate, and only the first is happening?
Go out of scope, yes. Destroyed, no. Want to test? No problem. Do
the following in a perl script.
my($funnything);
print"Value of funnything is $funnything";
$funnything="Uh oh... check this out";
You'll find some interesting results on your second interation :-).
Even funnier might be the folowing...
dosomefunnystuff();
sub dosomefunnystuff {
my($funnystuff);
if($funnystuff eq "funny") {
dosomefunnystuff();
}
print "Funnystuff is $funnystuff";
$funnystuff="funny";
}
Try that, and you will truely find out how memory inefficient modperl
is :-). I haven't tested that second one, but based on what I know
about how perl works... it should prove... interesting.
Thanks,
Shane.
>
> - Perrin
mod_perl with jpl
I have a requirement to make use of some third party software written in Java. I would like to get my mod_perl based scripts to talk to this software. To that end I am interested in the jpl shipped with 5.6. Has anyone successfully integrated this with mod_perl on Solaris? If so, how did you build Perl. I am particularly interested in the threading options. More generally, how do the threading options in Perl influence mod_perl? Does mod_perl simply ignore them, being process based? Is it ill-advise to enable threading when you will be using mod_perl? -P
Fw: Apache::Registry error message?
OK, it happended again. Here is the error log snippet Can't undef active subroutine at /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/Registry.pm line 102. I think i may know a little more about the cause this time thought. It happened immediatly after I made a VERY minor change (put quotes around text) to my pre-loaded mod_perl cgi script. Perhaps apache::registry is having difficulty rebuilding my scripts when I make changes? - Original Message - From: "Jason Terry" <[EMAIL PROTECTED]> To: "Doug MacEachern" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, April 12, 2000 9:44 AM Subject: Re: Apache::Registry error message? > Server Version: Apache/1.3.12 (Unix) > mod_perl/1.22 > PHP/3.0.15 > mod_ssl/2.6.2 > OpenSSL/0.9.5a-beta1 > Server Built: Apr 4 2000 15:57:17 > > It has only happened a to a dozen or so children. And it *seems* to only have >happened to 1 child in the server. It has only > happened once since I upgraded my server to 1.22. I reviewed my log files and it >seems to have happend more often with 1.21 > > ps. Its been several days (Apr 6th) since it last happened. > > - Original Message - > From: "Doug MacEachern" <[EMAIL PROTECTED]> > To: "Jason Terry" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Tuesday, April 11, 2000 9:57 PM > Subject: Re: Apache::Registry error message? > > > > On Fri, 7 Apr 2000, Jason Terry wrote: > > > > > Does anybody know how to track down what is causing this error. It seems that >Apache::Registry is trying to undefine some > handler, > > > but I don't know what handler or where. Any ideas? > > > > > > > > > [Thu Apr 6 11:06:26 2000] [error] Can't undef active subroutine at > /usr/lib/perl5/site_perl/5.005/i386-linux/Apache/Registry.pm > > > line 102. > > > > what version of mod_perl and Apache are you using? >
Re: Modperl/Apache deficiencies... Memory usage.
[EMAIL PROTECTED] wrote: > Now with modperl the Perl garbage collector is > NEVER used. Because the reference count of those variables is never > decremented... it's because it's all in the registry, and it's hard to > tell... hmm... what should I throw away, and what should I keep? ;-). What I know about Perl internals could fit on the head of a pin, but this strikes me as a very odd statement. If the garbage collector is never used, why do my lexical variables go out of scope and get destroyed? There are mod_perl packages like Apache::Session that absolutely depend on garbage collection of lexical variables to work. Are you saying that destroying the variables and actually reclaiming the memory are separate, and only the first is happening? - Perrin
Re: Apache::AuthCookie or Apache::AuthDBI or Apache::???
> "KF" == Kenneth Frankel <[EMAIL PROTECTED]> writes: KF> What's the best way to authenticate users? I have a site where the entire KF> site is to be protected. I want to log users in at the front of the web For a site whose contents are entirely protected, I'd use basic auth with a cookie override. That's what I've done in the past. Neither of these require perl or mod_perl, though. See the apache module registry at www.apache.org for references to my mod_auth_cookie which tricks Apache into converting a cookie into a basic auth header. How you set the cookie is up to you... How you authenticate depends mostly on your needs of maintaining the database. I've used flat files with htpasswd, dbm files with htpasswd and my own home brew scripts, and MySQL tables with my own scripts. None of these require mod_perl, either, but you can use mod_perl based versions of the necessary authentication modules.
Re: [Slightly OT] IPC::Open3 broken in mod_perl/perl 5.6.0?
Hi, I have also had this problem. I checked the modperl-cvs archive and this problem has been fixed in the development release. I still have an problem using IPC::Open2. This can be demonstrated by: use IPC::Open2; $pid = open2(\*A, \*B, '/usr/bin/ls'); The error log shows: [error] Can't locate object method "FILENO" via package "Apache" at /usr/local/lib/perl5/5.6.0/IPC/Open3.pm line 183. I do not understand enough about the perl/mod-perl guts to produce a patch. Any help appreciated. Thanks, Richard -- Richard Titmuss Email: [EMAIL PROTECTED] B55 Rm122, BT Laboratories Martlesham HeathTel: +44 (0)1473 640306 Ipswich, Suffolk, IP5 3RE, UK Fax: +44 (0)1473 646885
[FIXED] make test indicates server won't start
I previously posted a question regarding installing mod_perl. Specifically, when I ran "make test", the script said it started the server, then said it was still waiting for the server to warm up, and finally died. I had built mod_perl in a directory within my home directory. The permissions on my home directory itself were 700. I was also building the program as root, probably a bad idea in itself. At any rate, the server ran as root and honored the permissions on my home directory; the script interpreted the "Forbidden" error as the server not being up, and that produced the message I got. So if I had either changed the permissions on my home directory to 755 or built the package as myself, it probably would have worked. I just changed the permissions and then changed them back when done, and that worked fine. steve
Apache::AuthCookie or Apache::AuthDBI or Apache::???
What's the best way to authenticate users? I have a site where the entire site is to be protected. I want to log users in at the front of the web site, and keep them logged in as they travel around. I was trying to get AuthCookie to work but haven't been successful so far. Should I continue down this route? Is Apache::Session + AuthBasic better? Or is AuthDBI? I have a mysql database handy. What's the most popular Auth method nowadays? Is there a popularity/usage chart compiled anywhere? Thanks in advance! Kenneth
Help needed with Apache::AuthCookie 2.007
Could someone provide a good FAQ or example of how to impliment this thing? The package documentation's "just copy the test script" example I'm sure is a great time-saver for the author but when one has problems it's really a pain with all the unrelated testing code. I'm having problems and it's probably my mod-perl configuration but I can't sort out what's wrong comparing to the test-script non-example. If someone could provide their setup without the "WhatEver" and "Sample" namings it'd be really appreciated! Thanks, Kenneth P.S. If you need to fix what's wrong (thanks, man!), the errors are configuration error: couldn't check user. No user file?: /bqbin/gui.pl
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
On Mon, 17 Apr 2000, Vivek Khera wrote:
> > "MS" == Matt Sergeant <[EMAIL PROTECTED]> writes:
>
> >> adding handlers as easy as adding Registry scripts. I guess it is
> >> sort of an ultra-light-weight Registry, in some sense.
>
> MS> I've got something pretty similar. Let me know if you want some code.
>
> Sure; it is always good to see other ideas...
>
> Which handler phase did you tie into? I'm thinking just to go along
> the lines of Apache::Registry and use the content phase.
PerlFixupHandler. That way I eliminate stat() calls. At the end of the
fixup handler I push an ordinary PerlHandler onto the stack, which deals
with the main content delivery. But I suppose you could have the Fixup
handler determine what phase to use, via a call to a method in the module
you've used.
Anyway, here's the relevant bit of code, typed in and untested because
it's part of something much larger, so it might not quite work, but
hopefully you'll get the idea:
package Whatever;
sub fixup {
my $r = shift;
my $loc = $r->location;
my $handler = $r->uri;
if ($loc) {
$loc =~ s/\.\*$//; # remove wildcards
$loc =~ s/^\^//; # remove anchor at start
$prefix = $loc;
$handler =~ s/^\Q$loc\E//; # strip location from uri
}
else {
# handler starts from / (sensible?)
$handler =~ s/^\///;
}
$handler =~ s/\//::/g; # change / to ::
$handler =~ s/(.*)::/$1\->/; # change last :: to ->
my $module = $handler;
$module =~ s/\->.*$//;
eval {
require $module;
import $module;
}
if ($@) {
return 404;
}
no strict 'refs';
my $handler = $module->which_handler || 'PerlHandler';
$r->push_handlers( $handler, \&{$handler} );#
return OK;
}
Stick it as a PerlFixupHandler in a or
directive.
--
Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
> "MS" == Matt Sergeant <[EMAIL PROTECTED]> writes: >> adding handlers as easy as adding Registry scripts. I guess it is >> sort of an ultra-light-weight Registry, in some sense. MS> I've got something pretty similar. Let me know if you want some code. Sure; it is always good to see other ideas... Which handler phase did you tie into? I'm thinking just to go along the lines of Apache::Registry and use the content phase.
Re: [RFC] Transitioning from Apache::Registry to Apache handlers
> "DT" == Drew Taylor <[EMAIL PROTECTED]> writes: DT> are beginning the transition to Apache handlers. One other thing that I DT> would love is a module to do checkboxes/pull-down list generation ALA DT> CGI.pm. I might rip off some code and create a module myself. I think it Have a look at CGI::Form. I think it needs CGI::Base and/or CGI::Request. These are dated modules, and have not been maintained in a long time as far as I can see, but they were intended as a more object-oriented CGI API than CGI.pm.
Re: [RFC] Transitioning from Apache::Registry to Apache handlers
Matt Sergeant wrote: > > On Mon, 17 Apr 2000, Vivek Khera wrote: > > > But, I've been toying with the idea of writing an Apache::Dispatch > > module that would take all URL's of the form something like > > > > http://localhost/perl/My/Module/handlerfunc > > > > and dispatch the call to My::Module::handlerfunc() > > > > Assuming that My::Module was already loaded, otherwise it would > > generate a run-time error (or maybe we'd do a "require" -- dunno yet). > > The URL trigger /perl/ would be configurable, of course. > > > > Does anyone have something like this already? It would certainly make > > adding handlers as easy as adding Registry scripts. I guess it is > > sort of an ultra-light-weight Registry, in some sense. > > I've got something pretty similar. Let me know if you want some code. Since I believe I'm the one that started this thread, I'd love to see some code to enable handlers on the fly. In my case I only have perhaps a half-dozen handlers, but multiply this times a lot of virtual hosts and it then becomes a great boon. IMHO, I think this would be a very useful module to people like me who are beginning the transition to Apache handlers. One other thing that I would love is a module to do checkboxes/pull-down list generation ALA CGI.pm. I might rip off some code and create a module myself. I think it would be a good first project (or maybe not - who knows until I try?) -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
On Mon, 17 Apr 2000, Vivek Khera wrote: > But, I've been toying with the idea of writing an Apache::Dispatch > module that would take all URL's of the form something like > > http://localhost/perl/My/Module/handlerfunc > > and dispatch the call to My::Module::handlerfunc() > > Assuming that My::Module was already loaded, otherwise it would > generate a run-time error (or maybe we'd do a "require" -- dunno yet). > The URL trigger /perl/ would be configurable, of course. > > Does anyone have something like this already? It would certainly make > adding handlers as easy as adding Registry scripts. I guess it is > sort of an ultra-light-weight Registry, in some sense. I've got something pretty similar. Let me know if you want some code. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: [OT] mysql-modules for Win32 platform
Erich Markert wrote:
> I've been trying to get the msql-mysql-modules compiled and installed on
> my Win98 machine for a couple weeks without much luck.
I managed to get these working on NT4 with both 5.005_03 and 5.6.0 (both
built myself from the standard distribution, not the ActiveState build)
after a bit of hacking...
> I tried using the latest version of perl 5.6 from active state but ran
> into nothing but problems. Basically running perl Makefile.PL for
> Data::ShowTable (a required module) failed because the version of perl
> couldn't be determined - even after reinstalling.
I also had trouble with this when I had mSQL installed. It said "Unable to
find a perl 5" and then proceeded to name the files it was looking for
(including perl.exe!) and the directories where it was looking (including
D:\perl5\bin, which is where it was!). To my surprise, I found that
uninstalling mSQL and then trying to build Data::ShowTable again worked
fine! Weird. Anyway, I've now ditched mSQL in favour of the much better
MySQL which doesn't suffer this problem.
I don't know if this is the same problem you had -- you might have a
different problem because you're using the ActiveState build? I never had
much luck building any CPAN modules with that, which is why I never use
it...
I do still get 17/17 tests failed when running "nmake test" (!!!), but its
enough to stop msql-mysql-modules complaining that a pre-requisite is
missing.
> I finally reverted back the a previous version of perl (Gurusamy
> Sarathy's version 5.004_02) and was able to get Data::ShowTable and DBI
> installed but now when I run perl Makefile.PL for Msql-Mysql-modules I
> receive these errors:
>
> Note (probably harmless): No library found for 'm.lib'
I got a similar message regarding "-lm" which I just ignored (!!!... well,
it said it was probably harmless :-)
I also found that I had to hack the Makefile generated by "perl Makefile.PL"
to change the two lines which say:
-e ppp '...' '...' '...'
to:
-e "ppp('...', '...', '...')"
and I hacked the Makefile in the mysql sub-directory to change:
OTHERLDFLAGS = -LD:\mysql/lib/opt
to:
OTHERLDFLAGS = -LIBPATH:D:\mysql/lib/opt
None of this was necessary on my Solaris 2.6 box, however, where everything
went like a dream...
- Steve Hay
Re: [summary] Re: front end proxy and virtual hosts
Looks good; I'd recommend keeping *.html files on the front-end as well, since they tend to be static, and also any traditional *.cgi since they don't need mod_perl's bloat on the fork/exec. Also, specifying "Port 80" inside each virtual on the back-end is not necessary, though perhaps setting a new DocumentRoot might make sense. Perhaps this paragraph: If your server is configured to run traditional CGI's as well as mod_perl CGI programs, then it would be beneficial to configure the front-end server to run the traditional CGI's directly. This can be done by altering the C rewrite rule to add C<|cgi> at the end, or adding a new rule to handle all C locations locally. Similarly, static HTML pages can be served by the front-end server by adding C<|html> to the rule. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 PGP & MIME spoken herehttp://www.kciLink.com/home/khera/
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
On Mon, 17 Apr 2000, Vivek Khera wrote: > > "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: > > SB> Of course, anyone has a sample section handy? I'm still an > SB> C fan, to be changed soon :) > > I don't see what sections have to do with using or not > Apache::Registry instead of handlers... Because when you have hundreds of different 's to configure (and there is a lot of repetition), it's easier with Perl. Isn't it? At least that's what people said on the list. > But, I've been toying with the idea of writing an Apache::Dispatch > module that would take all URL's of the form something like > > http://localhost/perl/My/Module/handlerfunc > > and dispatch the call to My::Module::handlerfunc() > > Assuming that My::Module was already loaded, otherwise it would > generate a run-time error (or maybe we'd do a "require" -- dunno yet). > The URL trigger /perl/ would be configurable, of course. > > Does anyone have something like this already? It would certainly make > adding handlers as easy as adding Registry scripts. I guess it is > sort of an ultra-light-weight Registry, in some sense. Cool! __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
RE: [RFC] Transitioning from Apache::Registry to Apache handlers
> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: SB> Of course, anyone has a sample section handy? I'm still an SB> C fan, to be changed soon :) I don't see what sections have to do with using or not Apache::Registry instead of handlers... But, I've been toying with the idea of writing an Apache::Dispatch module that would take all URL's of the form something like http://localhost/perl/My/Module/handlerfunc and dispatch the call to My::Module::handlerfunc() Assuming that My::Module was already loaded, otherwise it would generate a run-time error (or maybe we'd do a "require" -- dunno yet). The URL trigger /perl/ would be configurable, of course. Does anyone have something like this already? It would certainly make adding handlers as easy as adding Registry scripts. I guess it is sort of an ultra-light-weight Registry, in some sense. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 PGP & MIME spoken herehttp://www.kciLink.com/home/khera/
[OT] mysql-modules for Win32 platform
I've been trying to get the msql-mysql-modules compiled and installed on my Win98 machine for a couple weeks without much luck. I tried using the latest version of perl 5.6 from active state but ran into nothing but problems. Basically running perl Makefile.PL for Data::ShowTable (a required module) failed because the version of perl couldn't be determined - even after reinstalling. I finally reverted back the a previous version of perl (Gurusamy Sarathy's version 5.004_02) and was able to get Data::ShowTable and DBI installed but now when I run perl Makefile.PL for Msql-Mysql-modules I receive these errors: Note (probably harmless): No library found for 'm.lib' Usage: xsubpp [-v] [-C++] [-except] [-prototypes] [-noversioncheck] [-nolinenumb ers] [-s pattern] [-typemap typemap]... file.xs Writing Makefile for DBD::mysql Writing Makefile for Msql-Mysql-modules My questions are: 1. Is there a binary version of *just* DBI,Msql-Mysql-modules for Win32? 2. If not, is there a PPM of the above for Activestate's perl 5.6 for Win32 (I did a search for DBD::mysql but it failed)? TIA, Erich -- __ Mr. Erich L. Markert [EMAIL PROTECTED] Computer Learning Center TEL (914)422-4328 Pace University 1 Martine Ave White Plains, New York 10606-1932 Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
RE: Segfault on DBI->Connect
Jochen,
> If you are using the DBD-mysql sources, as distributed by me, the
> mysql_real_connect function will *never* be called with a NULL
> argument. This cannot happen, if mysql_init() is called before
> mysql_real_connect(). (Unless you are using some patches that I have
> recently reached me from the mod_perl mailing list, but that I haven't
> verified yet.) Calling mysql_real_connect with mysql==NULL will surely
> cause a SEGFAULT.
>
I'm using:
Redhat 6.1 (Linux 2.2.12-20RS )
Apache/1.3.12 (from distribution)
mod_perl: 1.22 (compiled from source, running as a DSO through APXS)
mysql Ver 9.36 Distrib 3.22.27 (from distribution)
perl 5.005_03 (from distribution)
Msql-Mysql-modules-1.2211 (compiled form source, retreived from CPAN)
DBI-1.13 (compiled form source, retreived from CPAN)
None of which are sporting any modifications.
Below is a backtrace of my segfault received on DBI->Connect (sorry but my
perl and apache binaries are stripped)... you can see that mysql_close is
being called with a null argument, rather than mysql_real_connect as
indicated in some of the other backtraces reported.
-+-
Starting program: /usr/local/apache/bin/httpd -X
Program received signal SIGSEGV, Segmentation fault.
mysql_close (mysql=0x0) at libmysql.c:1555
1555 end_server(mysql);
#0 mysql_close (mysql=0x0) at libmysql.c:1555
#1 0x403bf254 in __DTOR_END__ ()
from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#2 0x403ac0dd in mysql_dr_connect ()
from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#3 0x403ac420 in _MyLogin ()
from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#4 0x403ac48f in mysql_db_login ()
from /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
#5 0x403affd8 in XS_DBD__mysql__db__login ()
...
-+-
Any suggestions for a fix?
Regards,
Drew Degentesh
> -Original Message-
> From: Jochen Wiedmann [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, April 15, 2000 6:57 PM
> To: Doug MacEachern
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Segfault on DBI->Connect
>
>
>
>
> On Tue, 11 Apr 2000, Doug MacEachern wrote:
>
> > On Tue, 4 Apr 2000 [EMAIL PROTECTED] wrote:
> >
> > > I've been seeing the same segfault-on-connect problem
> with Apache 1.2.12
> > > + mod_perl 1.22 + DBI 1.13 + Msql-Mysql-modules 1.2211.
> The segfault is
> > > due to a null first argument being passed to mysql_real_connect().
> > >
> > > Running Apache with a -X argument yields the following
> backtrace when my
> > > mod_perl module does a DBI->connect (str, username,
> passwd, { options }).
> > > Note the null mysql argument
> > > |
> > > V
> > > #0 0x80ef5b7 in mysql_real_connect (mysql=0x0,
> > > host=0x8a99db8 "hostname.brown.edu", user=0x8a9b550
> "username",
> > > passwd=0x8a9b568 "password", db=0x8a99e40
> "databasename", port=3306,
> > > unix_socket=0x0, client_flag=0) at libmysql.c:1125
> > > #1 0x402d01fd in mysql_dr_connect ()
> > >from
> /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> > > #2 0x402d0540 in _MyLogin ()
> > >from
> /usr/lib/perl5/site_perl/5.005/i386-linux/auto/DBD/mysql/mysql.so
> > >
> > > The mysql_real_connect routine does a set_sigpipe(mysql),
> which triggers
> > > the segfault.
>
> So my question remains: Why the heck *are* you passing a NULL
> argument?
> Is this because of some bug in the DBD::mysql driver or are you using
> modified sources?
>
> Btw, Doug, as I see the sigpipe thing: What do you recommend for the
> DBD::mysql driver? (Remember the "MySQL morning bug"?) Should we
> enable or disable SIGPIPE?
>
>
> Thanks,
>
> Jochen
>
>
>
RE: Modperl/Apache deficiencies... Memory usage.
On Mon, 17 Apr 2000, Paul G. Weiss wrote: > Is this still true under 5.6, now that weak references > are available? Yes. You still have to do a lot of re-implementation to make weak refs work, and your users have to have the WeakRef module from CPAN. Not a nice situation. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
Re: Modperl/Apache deficiencies... Memory usage.
Gunther- (What follows is some servlet talk... and anyone interested in a mod_perl garbage collector?) > If you want the ultimate in clean models, you may want to consider coding > in Java Servlets. It tends to be longer to write Java than Perl, but it's > much cleaner as all memory is shared and thread-pooling libraries do exist > to restrict 1-thread (or few threads) per CPU (or the request is blocked) > type of situation. This is sorta OT in this present thread... however. I'm not so sure about your statement that Java apps take longer. My experience is the opposite. (And I have quite a lot of experience in writing servlets) However, your next comment hits the nail on the head... buggy, and one script blown kills the entire engine. Not only that, but if memory usage spikes over the memory setting you used when starting the engine the whole thing blows up in your face. (Basically new instances of requests for servlets get messed up) The whole memory issue with java is almost worst... although with competent admining it can be "not too bad". Then of course theres the speed issue with java... though TowerJ would fix this up nicely :-). > > However, I would stress that speed/threading is not the only name in the > game. Reliability is another concern. Frankly, I have seen a lot of buggy > servlets crash the entire servlet engine making a web site useless. > Generally if there is a core dump in an Apache/Mod_perl process, the worst > is that one request got hosed. Gotta love that! :). Well... I've seen a little worse, but not much. Doesn't touch the problems you can have with JServ and kin. Once I had a really mission critical JServ engine die, and went on a vacation... it didn't get back up until I got back. This put JServ on the non-use place in my book. You really need 24hr staffing/notification to use a servlet engine... major bummer. > > I am resigned to the fact that all languages are buggy, and so I like > engineering architectures that support buggy languages (as well as buggy > app code). Hehe... the essential problem with modperl comes down to this... Garbage collector?...??? Nope... it's not there. I've written a real basic garbage collector that might be able to be adapted to modperl. Okay... now here goes: The problem...: The way the perl garbage collector works is there is a reference count for each variable on the stack. There are different types of variables, but basically two types: "my'd" lexicals, and those that are not :-). (There is the local() stuff too, but that's just stack manipulation of non-my'd type) Basically within the structure of mod_perl almost every variable you actually use is of the lexical variety. Lexical variables are stored within the CV of whatever package your working with. There is an AV (Array value) of AV's within that CV that stores all the lexicals. The first AV within the variable AV stores the name of the variable. The rest of the AV's under that store the variable value for various levels of recursion. Now with modperl the Perl garbage collector is NEVER used. Because the reference count of those variables is never decremented... it's because it's all in the registry, and it's hard to tell... hmm... what should I throw away, and what should I keep? ;-). This contributes to a good deal of speed... because you hardly EVER have to create more instances of variables after running the program for the first time. It's all stored in memory... wow, that's GREAT!... not. Well, it is, but basically it sucks up tons and tons of memory. This is why that requiring the scripts before fork;ing can be okay, but not great, because each process still has to store all these stack variables again for every "package/script" within mod_perl. Now... I could see a couple solutions. 1) "Smartly" route script requests to the appropriate set of apache instances. So basically not every apache instance would have to store the variable and code info for every script that has to be run. 2) Make a garbage collector for modperl. This would be pretty cool... but programmatically it's really really hard. And there is no guarantee that the whole variable design would change in the future releases of perl. I could see a garbage collector that killed the values within the stack, and wiped out totally the existance of recursive layers. I'm fully onboard with submitting my code and helping out if someone besides me is interested in this. (I don't have time to do it solo... besides I need someone to bounce ideas off of. This is a really hard thing to do, and it would be pretty easy to break a lot of stuff in the process of building this.) The use of a garbage collector would have several benefits... it would get rid of the "security hole" that I percieve in mod_perl. It would also lower the process overhead... and generally be really cool. (BTW: If anyone that knows the internals of mod_perl is seriously interested in working on a garbage cole
RE: Modperl/Apache deficiencies... Memory usage.
Is this still true under 5.6, now that weak references are available? -P > -Original Message- > From: Matt Sergeant [mailto:[EMAIL PROTECTED]] > Sent: Monday, April 17, 2000 4:14 AM > To: Leslie Mikesell > Cc: (Gunther Birznieks); [EMAIL PROTECTED] > Subject: Re: Modperl/Apache deficiencies... Memory usage. > > > On Sun, 16 Apr 2000, Leslie Mikesell wrote: > > > Do you happen to know of anyone doing xml/xsl processing in > > servlets? A programmer here has written some nice looking stuff > > but it appears that the JVM is never garbage-collecting and > > will just grow and get slower until someone restarts it. I > > don't know enough java to tell if it is his code or the xslt > > classes that are causing it. > > Perl's XML::DOM creates circular references which have to be manually > deleted with the XML::DOM::Node->dispose method. It's fairly > likely that > Java implementations work in a similar fashion. > > -- > > > Fastnet Software Ltd. High Performance Web Specialists > Providing mod_perl, XML, Sybase and Oracle solutions > Email for training and consultancy availability. > http://sergeant.org http://xml.sergeant.org >
dynamically set AuthUserFile
Hi, I'm using part of the URL to tell perl::dbi what DB to connect to. www.mysite.com/mydb/index.html will connect to mydb. I will be creating many different environments. At the moment I edit the httpd.conf file as I add each environment. How can I tell apache what AuthUserFile to use dynamically? And set AuthName dynamically? Any help or pointers in the right direction will be very much appreciated. regards Scott Scott Alexander tietoverkkosuunnittelija [EMAIL PROTECTED] gsm: +358 (0)40 7505640
Re: Modperl/Apache deficiencies... Memory usage.
On Sun, 16 Apr 2000, Leslie Mikesell wrote: > Do you happen to know of anyone doing xml/xsl processing in > servlets? A programmer here has written some nice looking stuff > but it appears that the JVM is never garbage-collecting and > will just grow and get slower until someone restarts it. I > don't know enough java to tell if it is his code or the xslt > classes that are causing it. Perl's XML::DOM creates circular references which have to be manually deleted with the XML::DOM::Node->dispose method. It's fairly likely that Java implementations work in a similar fashion. -- Fastnet Software Ltd. High Performance Web Specialists Providing mod_perl, XML, Sybase and Oracle solutions Email for training and consultancy availability. http://sergeant.org http://xml.sergeant.org
