Re: Database Pooling
Sure. And beware of connections that are returned to the pool without being rollbacked, too - the app then deadlocks itself because it holds locks in the database and doesn't know it does. I get bitten by this under JDBC every so often, when an exception is thrown at the wrong time. Sounds like you should have some more code in your finally blocks. :) KS
Re: Database Pooling
Not necessarily, that would be your MAXIMUM number of simultaneous connections, unless you connect to all the datababases when a children is spawn (which would be pretty dull methinks, I prefer lazy algorithms). Well, it's going to be a pretty strange environment that doesn't have a database connection in every process. After a certain number of requests, you can pretty much be assured that your database application has been hit in every process and therefore every process has a connection. Thinking of it as just the maximum is semantically correct, but in reality, thinking of it as your common load is the best practice. Kenny Smith
Re: [mp1.0] linking libperl.so fails because of G: command not found
Hi Frank, This is how I configured apache: ./configure --prefix=/usr/local/kenny --enable-module=rewrite --enable-shared=rewrite --enable-suexec --suexec-caller=nobody --suexec-docroot=/usr/www --enable-module=so and this is how I configured mod_perl: perl Makefile.PL \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ EVERYTHING=1 The problem was that it just wasn't filling in that one value in the configure script, so it didn't know what binary to use to link after compilation. Kenny Smith [EMAIL PROTECTED] wrote: Kenny, I am not sure if I can help you much, but I was succesful in building this combination. The main differences I see between our configuration is that you are using SunOS in Intel wheras I am using SPARC and that you obviously tried to build mod_perl as DSO. What were the command lines you used to configure mod_perl and Apache? Do you need mod_perl running as a DSO? Regards, Frank Kenny Smith 13.12.2002 18:57 An: [EMAIL PROTECTED] Kopie: Thema: [mp1.0] linking libperl.so fails because of G: command not found Hello, I'd like to report an installation bug. I've looked around and if this has already been reported, or is mentioned in documentation, I apologize for the repeat. The symptom is when make tries to link libperl.so it dies with G: command not found I tracked down PERL_LD was blank in apaci/Makefile. I put gcc in there, and it linked and built properly. One one of the subsequent lines there was a -G at the start of PERL_LDDLFLAGS, so I assume that is where the G came from. Versions: SunOS 5.8 x86 apache 1.3.27 mod_perl 1.27 gcc version 2.95.3 20010315 (release) autoconf (GNU Autoconf) 2.53 GNU Make version 3.79.1 If there is any other information you need, please let me know. Kenny Smith JournalScape.com
RE: [mp1.0] linking libperl.so fails because of G: command not found
Hi Keith, Thanks for the reply. I've already figured been able to compile and get mod_perl running... I'm trying to report a bug in the configure script. It didn't set the PERL_LD variable in the Makefile. I want to try to find out why so that it can be fixed, so that other unsuspecting users don't have this same problem. :) Kenny Smith -Original Message- From: Keith McGlauflin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 12:38 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [mp1.0] linking libperl.so fails because of G: command not found Hi Kenny, We use SunOS 5.8 with mod_perl 1.27 on SPARC processors. We don't use DSO but build mod_perl statically into httpd. Here is the configure we use for mod_perl: CC=cc \ /opt/perl5/bin/perl Makefile.PL APACHE_SRC=../apache-1.3.27/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 and for apache: CC=cc CFLAGS=-O -DEAPI \ ./configure --prefix=/web/adm/apache_1.3.27 \ --activate-module=src/modules/perl/libperl.a (this is actually a simplified version; we also enable a bunch of other shared modules) Note that 'cc' above is the Sun C compiler (ours is installed in /opt/SUNWspro/bin/cc). If you use gcc make sure you use it for both mod_perl and apache. I hope this helps! Keith This is how I configured apache: ./configure --prefix=/usr/local/kenny --enable-module=rewrite --enable-shared=rewrite --enable-suexec --suexec-caller=nobody --suexec-docroot=/usr/www --enable-module=so and this is how I configured mod_perl: perl Makefile.PL \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ EVERYTHING=1
[mp1.0] linking libperl.so fails because of G: command not found
Hello, I'd like to report an installation bug. I've looked around and if this has already been reported, or is mentioned in documentation, I apologize for the repeat. The symptom is when make tries to link libperl.so it dies with G: command not found I tracked down PERL_LD was blank in apaci/Makefile. I put gcc in there, and it linked and built properly. One one of the subsequent lines there was a -G at the start of PERL_LDDLFLAGS, so I assume that is where the G came from. Versions: SunOS 5.8 x86 apache 1.3.27 mod_perl 1.27 gcc version 2.95.3 20010315 (release) autoconf (GNU Autoconf) 2.53 GNU Make version 3.79.1 If there is any other information you need, please let me know. Kenny Smith JournalScape.com
$ENV{'REMOTE_USER'} getting clobbered?
Hello,
I'm using mod_perl as a replacement for CGI. We are getting strange behavior
where $ENV{'REMOTE_USER'} isn't being set correctly.
The script is protected by an .htaccess type of authentication, so when I
log in as 'kenny', $ENV{'REMOTE_USER'} should be equal to 'kenny'. However,
every once in awhile, $ENV{'REMOTE_USER'} will be equal to someone else's
login name, even though I'm still logged in as 'kenny' when I execute the
script. Does that make sense?
This system was working fine for 2 months or more, but recently the number
of users and the load on the machine has increased, and we have started
seeing the problem.
My theory is that %ENV is shared between requests and user 'bob' is
executing the script in the middle of my execution and $ENV{'REMOTE_USER'}
is getting overwritten in my execution with 'bob'. I believe the script is
taking longer to execute due to the load time which increases the window of
opportunity for REMOTE_USER to be clobbered.
Software involved:
apache 1.3.12
mod_perl 1.24
solaris 5.7
perl 5.005_03
Our sysadmins are working on building a new apache binary with up to date
versions, but I'd like to find out from the list if you have had this
problem before, and if you know why it is caused.
Kenny Smith
Persistant Data shared with other applications
Hi there, I'm seeing a strange bit of behavior and wanted to find out if anyone else is having this problem. I have two scripts, index.mod_perl and grapevine.mod_perl. They both use HTML::Template to generate their output. The template is not persistant between requests, but $main::tokens is persistant. $main::tokens is hashref that contains a page title variable which is passed to the template. The index.mod_perl's tokens contains the page title Employee Portal and the grapevine.mod_perl contains the page title Grapvine Employee Utility. They both use the same html header file during output, which is customized by the page_title token. My problem is that sometimes, when I go to grapevine.mod_perl, it shows me the Employee Portal title. It seems that $main::tokens from index.mod_perl is being shared as $main::tokens to grapevine.mod_perl. Has anyone had this kind of thing happen? Kenny Smith
mod_rewrite + mod_perl
Hello all, For the first part of my project, I'm just using mod_perl as a replacement for CGI. I'm trying to execute a mod_perl script via mod_rewrite, but it doesn't seem to be persisting. In my httpd.conf, I've got: Files *.mod_perl SetHandler perl-script PerlHandler Apache::Registry PerlSendHeader On Options ExecCGI /Files ... RewriteRule ^/([^/^.]+)/?$ /path/show_journal.mod_perl [T=application/x-httpd-cgi,E=NICKNAME:$1,L] The above is used to catch the following URL: http://www.journalscape.com/kenny/ The nickname 'kenny' is captured from the url and sent to the script via an environment variable. It executes show_journal.mod_perl perfectly well, but the script does not remain resident in memory. Do I need to call it differently? Any help is appreciated. :) Kenny Smith [EMAIL PROTECTED]
