Re: Apache::Registry script problem
On Wed, 24 May 2000, Drew Taylor wrote: Hi all, I'm having a serious, but intermittent, problem with my Apache::Registry scripts. I have 2 (soon to be more!) site running on the same physical server. Each site is driven by a set of short perl-script scripts. The scripts execute code in OO modules that are shared among all servers. The scripts are identical between all sites except for the following: (index.pl) my $SITENAME = 'cloudstock'; my $SITEID = 1; OR my $SITENAME = 'wiredstock'; my $SITEID = 2; (all others in /cgi-bin) my $search = eLogix::Search-new($CGI, 'cloudstock', 1); $search-blah OR my $search = eLogix::Search-new($CGI, 'wiredstock', 2); $search-blah ETC The part that changes is the 'cloudstock' and '1'. However, I occasionally (and not reliably) get a page from cloudstock.com using the wiredstock.com scripts! On some debugging, I can verify that when this happens the script has the wrong values. It seems that apache is confused and sometimes serves the wrong script for the given domain! sounds like the 'variable won't stay shared' problem, see http://perl.apache.org/guide/
Re: Apache::Registry script problem
Doug MacEachern wrote: On Wed, 24 May 2000, Drew Taylor wrote: The part that changes is the 'cloudstock' and '1'. However, I occasionally (and not reliably) get a page from cloudstock.com using the wiredstock.com scripts! On some debugging, I can verify that when this happens the script has the wrong values. It seems that apache is confused and sometimes serves the wrong script for the given domain! sounds like the 'variable won't stay shared' problem, see http://perl.apache.org/guide/ I have tried many things to solve this problem. Many thanks go to Geoffrey Young who helped me privately (and clued me into a great solution to another future maintenance problem as well!). In the end, I have decided that it is Stronghold's fault. :-) So I compiled and configured a seperate apache(1.3.12)/mod_perl(1.24) to run the non-SSL sites. I also use PerlSerVar to determine the sitename and siteID from within each VHost section. This enables me to alias a common cgi-bin for all sites and have one set of scripts for everyone. While I'm testing the new configuration, I'll turn PerlWarn On and see if I get any of the "won't stay shared" messages. Thus far, I haven't run into any problems with the new server/configuration... I'm keeping fingers crossed. Thanks to those people who suggested solutions. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: Apache::Registry script problem
On Thu, 25 May 2000, Drew Taylor wrote: I have tried many things to solve this problem. Many thanks go to Geoffrey Young who helped me privately (and clued me into a great solution to another future maintenance problem as well!). i glad your problem is solved, but can we keep all help on the list to prevent duplication of efforts? i get the feeling this is happening alot. it's a pity for folks to take time trying to help solve a problem that's already been solved :)
Re: Apache::Registry script problem
Doug MacEachern wrote:
On Thu, 25 May 2000, Drew Taylor wrote:
I have tried many things to solve this problem. Many thanks go to
Geoffrey Young who helped me privately (and clued me into a great
solution to another future maintenance problem as well!).
i glad your problem is solved, but can we keep all help on the list to
prevent duplication of efforts? i get the feeling this is happening
alot. it's a pity for folks to take time trying to help solve a problem
that's already been solved :)
I would be happy to post the responses between Geoffrey and I (with his
permission of course :-). A couple highlights:
1. StatINC off for production sites - can sometimes be flaky
2. $Apache::Registry::NameWithVirtualHost = 0; (for my original
configuration)
3. PerlFreshRestart Off
The above seemed to help, but something was still getting shared. So my
solution was to consolidate all the many individual scripts to one
central place. So now I have this in httpd.conf outside of all
VirtualHost sections:
ScriptAlias /cgi-bin/ "/thinkstock/mnt01/apache_1.3.12/cgi-bin/"
Directory "/thinkstock/mnt01/apache_1.3.12/cgi-bin"
AllowOverride None
Options +ExecCGI
SetHandler perl-script
PerlHandler Apache::Registry
Order allow,deny
Allow from all
/Directory
Then in each VHost section:
PerlSetVar SITENAME 'cloudstock'
PerlSetVar SITEID 1
# for any remaining scripts
Files *.pl
Options +ExecCGI
SetHandler perl-script
PerlHandler Apache::Registry
/Files
I also preloaded all the common scripts using Apache::RegistryLoader in
startup.pl.
Then I modified my scripts by adding:
my $r = shift;
my $SITENAME = $r-dir_config('SITENAME');
my $SITEID = $r-dir_config('SITEID');
...
my $object = Object-new($CGI, $SITENAME, $SITEID);
Thus far in testing, no signs of the "schizophrenia" has shown
themselves. Thus, I think the problem was primarily Stronghold. I had
been planing to implement the transparent proxy scheme outlined in the
guide, so now I just began it sooner than expected. :-)
BTW, this solution is for launching many similar sites using a common
backend code base and DB. They share common functinality across all
sites. The sites launched to date are http://www.cloudstock.com/
http://www.wiredstock.com/ and http://www.thinkstock.com/ They are stock
photography e-commerce with DL of purchased images.
--
Drew Taylor
Vialogix Communications, Inc.
501 N. College Street
Charlotte, NC 28202
704 370 0550
http://www.vialogix.com/
Apache::Registry script problem
Hi all, I'm having a serious, but intermittent, problem with my Apache::Registry scripts. I have 2 (soon to be more!) site running on the same physical server. Each site is driven by a set of short perl-script scripts. The scripts execute code in OO modules that are shared among all servers. The scripts are identical between all sites except for the following: (index.pl) my $SITENAME = 'cloudstock'; my $SITEID = 1; OR my $SITENAME = 'wiredstock'; my $SITEID = 2; (all others in /cgi-bin) my $search = eLogix::Search-new($CGI, 'cloudstock', 1); $search-blah OR my $search = eLogix::Search-new($CGI, 'wiredstock', 2); $search-blah ETC The part that changes is the 'cloudstock' and '1'. However, I occasionally (and not reliably) get a page from cloudstock.com using the wiredstock.com scripts! On some debugging, I can verify that when this happens the script has the wrong values. It seems that apache is confused and sometimes serves the wrong script for the given domain! Is there any known problems with this sort of thing happening? Is it a bug w/ my code or with mod_perl? I'm tearing my hair out trying to figure this out. Here's the server info: bash-2.03$ perl -v This is perl, version 5.005_03 built for sun4-solaris (from /perl-status) This is running on stronghold w/ mod_perl. Embedded Perl version 5.00503 for Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix) mod_perl/1.21 process 16288, running since Wed May 24 11:54:01 2000 Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration: Platform: osname=solaris, osvers=2.6, archname=sun4-solaris uname='sunos tsweb01.interpath.net 5.6 generic_105181-17 sun4u sparc sunw,ultra-250 ' hint=recommended, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O', gccversion= cppflags='-I/usr/local/include' ccflags ='-I/usr/local/include' stdchar='unsigned char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 alignbytes=8, usemymalloc=y, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldb -ldl -lm -lc -lcrypt libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-KPIC', lddlflags='-G -L/usr/local/lib' If anyone has ideas, I'd love to hear them. And of course, I can go into much greater detail if necessary. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
