Re: Apache::AuthDBI
Standard SQL allows for inserts without specifying field names. Personally, I think that it is more readable to specify the field names but it is quite common to not bother doing so. -- Douglas Leonard [EMAIL PROTECTED] On 19 Jun 2001, Alan E. Derhaag wrote: Christian Heiss [EMAIL PROTECTED] writes: [1 text/plain; iso-8859-1 (quoted-printable)] Hi, I'm using Apache::AuthDBI to verifying the users on my web site. I can connect to the the protected site, but there is a output in the error log: Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/Apache/AuthDBI.pm line 450 Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/Apache/AuthDBI.pm line 480 Use of uninitialized value at /usr/lib/perl5/site_perl/5.005/Apache/AuthDBI.pm line 481 [...] then I put it in the database with: my $sql = INSERT INTO table name VALUES($userid, $groupid, $pass, ...); of course, before I'm using the quote funktion ($dbh-quote($userid)...)... What database manager allows SQL without supplying the fields the values go into?
Re: Memory Usage
First off, the complaint about the lack of documentation for DSO being experimental is a bit offbase IMO. It isn't up to the mod_perl group to make sure RedHat includes complete documentation in their build of mod_perl. Also, this issue has been talked about many times on this mailing list. Sometime after mod_perl 1.20 was released there was talk that the DSO problems had been fixed. I can remember putting out a post myself on exactly how to cause the process size to grow using HUP or USR1 when using mod_perl 1.21 and 1.22-dev in order to disprove this. It is always best to check one of the archives first for this kind of problem IMO. I find it best to do a daily staggered shutdown/restart of each apache server and rotate the logs via a custom script. One minute of downtime per server per day isn't exactly noticeable when you have a load balancing system set up. On Tue, 7 Nov 2000, Buddy Lee Haystack wrote: Thanks, but as a RedHat [or other typical major distribution] user, I would never see the documentation you mentioned below. Since DSO is still experimental, would it not be an absolute necessity to include that information in the location where most users are directed to look for information about all things Apache? The first place I go to look for information is on the online documentation, and I know that the "experimental" nature of using DSO is not mentioned anywhere in "Apache 1.3 Dynamic Shared Object (DSO) Support" [http://www.apache.org/docs/dso.html]. It appears as if the "experimental" nature of DSO's under Apache is fairly well removed from view. Had the information you included below been clearly listed on Apache's website, in the proper location, many people would have made a choice not to use DSO. It appears as if the Apache Group has been a little less than candid in Apache's true support for DSO. IMHO There really needs to be a warning in the documentation on their website explicitly stating the info you've included below. snip -- Douglas Leonard [EMAIL PROTECTED]
Re: Milage may vary comments
On Fri, 18 Aug 2000, George Sanderson wrote: snip 2) 'Do not': "PerlFreshRestart On" in httpd.conf. Curiously enough, "PerlFreshRestart On" has always worked for me, even on the production servers. It's pretty damn useful too, giving servers a graceful restart everytime you upload a module... it'd be a pain to have to fully restart the server every time, that would mean like 10 seconds of downtime for the whole site. It's even more useful if you want to cache a large quantity of data in ram with the root process and then periodically refresh that data. I agree! What was happening to me, was that with "PerlFreshRestart On", I would get a segmentation fault every time used AutoIndex.pm. I removed the directive and the problem went away. I have seen other references to memory leaks and such. If anyone has suggestions as to why the "PerlFreshRestart On" would aggervate segment faults, I would like to here them. Some perl modules don't take well to being reinitialized. Stas mentions it in the guide, and it's been noted quite a few times here on the mailing list. Personally, I've never run into any modules that gave me any problems but I know they are out there. -- Douglas Leonard [EMAIL PROTECTED]
Re: Milage may vary comments
On Fri, 18 Aug 2000, Roger Espel Llima wrote: !) 'Do not' load mod_perl as a DSO. This should be a golden rule if you plan on HUPing your server with any regularity. 2) 'Do not': "PerlFreshRestart On" in httpd.conf. Curiously enough, "PerlFreshRestart On" has always worked for me, even on the production servers. It's pretty damn useful too, giving servers a graceful restart everytime you upload a module... it'd be a pain to have to fully restart the server every time, that would mean like 10 seconds of downtime for the whole site. It's even more useful if you want to cache a large quantity of data in ram with the root process and then periodically refresh that data. -- Douglas Leonard [EMAIL PROTECTED]
Re: Memory usage on reload and graceful -- still broken?
I had the same issue on Linux. My build had mod_perl compiled in static but mod_so was also compiled in. PerlFreshRestart was off, I didn't have any Perl sections, and no modules were loaded dynamically. My root process would grow by about 1MB each time it was HUPed. Something about mod_so was causing it to grow even though every module used was staticly compiled in. I tried everything I could think of when compiling to have mod_so compiled in without having memory growth problems, but eventually I gave up and eliminated it from my build. Douglas Leonard [EMAIL PROTECTED] On Thu, 20 Apr 2000, Doug MacEachern wrote: I have a static Solaris compilation, and have the same problems where the parent seems to grow by 1M each HUP. that's strange, do you have PerlFreshRestart On or some Perl sections? otherwise, kill -HUP with a static modperl is a noop.
Re: memory leak during server graceful restarts
I have run into the same issue also both with mod_perl as a DSO module or compiled staticly. I have tested it using apache-1.3.6 and apache-1.3.12 w/ mod_perl-1.22 and mod_perl-1.21. The memory growth also occurs if I HUP the server rather than sending USR1. Since the problem only occurs if mod_perl is loaded (DSO) or staticly loaded, I assume the problem lies in memory cleanup by modperl. Even if I do nothing other than have mod_perl installed and HUP the parent, the process will grow at a relatively rapid rate of over 1MB per HUP instance. The reason I noticed this is that I cache some relatively static database information in the parent process by assignment to a package's scoped hash variables in my startup.pl. I wanted to refresh this cache hourly just in case changes did happen to occur in the database tables I was caching. I am curious as to whether there is a better way to go about caching this data and refreshing it without the problem of watching your apache process size grow every time you HUP it. Any helpful hints would be appreciated. The platforms are various Linux kernels ranging from 2.0x to 2.3x. The majority of which are linux-2.2.10. Douglas Leonard [EMAIL PROTECTED] On Fri, 7 Apr 2000, Nikki Chumakov wrote: mod_perl probaly have memory leakage during rereading configs (e.g. on the apachectl graceful) My system: RH 6.1, linux-2.2.15pre17 glibc-2.1 apache-1.3.12 mod_ssl-2.6.2 russian patches (ftp.lexa.ru/pub/apache-rus/) PL29.4 mm-1.0.12 mod_perl-1.22 With mod_perl module enabled in httpd.conf every 'apachectl graceful' increase the data memory segment of parent server (and thus the child's as well).
