Good day. I'm hoping someone can shed some light on this.
I'm building a series of scripts with the intent to make them usable under both mod_perl and regular .cgi at the same time: I really don't want to have multiple versions of the code. "Just add this to your config file and you're set" sorta thing.
Since I'm building the code from scratch, I am currently using Apache::Registry, not ::PerlRun. My initial (newb) impression was that PerlRun is for quick porting, Registry is more proper.
I'm seeing two separate issues that I've yet to find an answer for, or really, any investigative tips on how I should proceed further. Likewise, they only happen sporadically (my MaxRequestsPerChild is set to 30, so once they do happen, they stick around for a few dozen loads, and then go away again).
Problem one involves (what I believe to be) shared variables amongst two different scripts, particularly the location of some template files that the scripts parse and display.
The scripts, installer.cgi and index.cgi, share nearly the exact same code, except for the location of the templates. The location of these template files is determined by $0 - if it's installer.cgi, we set $var to one directory, if it's index.cgi, we set $var to another directory. This $var setting is done in LibDB::Settings, which is used by both scripts.
You can see the scripts (installer.cgi, index.cgi), as well as the other modular code mentioned within, here:
http://cvs.sourceforge.net/viewcvs.py/libdb/LibDB/
What seems to happen is that index.cgi will randomly start serving data (a template) that installer.cgi previously served, and vice versa. Refresh enough times, and you'll get an error message that the $final_template doesn't exist but, from the file path reported, you can see that it's trying to load an index.cgi template from an installer.cgi directory (and vice versa). This smacks to me of shared variables in two places:
$LibDB::Settings::user_template_final (or $settings, the object). $main::data (either installer.cgi or index.cgi).
I'm not sure why this is (I can make a guess, in hindsight: the same child that cached $settings in installer.cgi is now using $settings in index.cgi, but I'm not sure how that could be, since uesr_template_final is determined at runtime). In the docs, shared vars are talked about a lot concerning nested subroutines and lexicals, but even counting mod_perl's handler(), I don't have any sub's in either index.cgi or installer.cgi. I didn't pursue much in the lexical direction besides a quick swapping of our() for my(), which also failed.
Turning on debugging, per the documentation, proved monumental. One single load of either script created a 217k .out file, and since I can only reproduce it maybe once out of 100 attempts, I fear the size and spelunking that would be necessary. I'm hoping there is an immediately "obvious" fix where such spelunking is folly.
The second problem I'm having could be related, I'm not sure. Taking a bird's eye view of things, this is the flow of a single request to the index.cgi script:
main > LibDB::Template > Text::Template > $tpl > LibDB::DB
What I'm seeing, with the same frequency as the above problem, is a warning that the object method ->connect can not be found. LibDB::DB->new returns a LibDB::DB::MySQL class (which itself uses DBI and DBD::mysql). LibDB::DB::MYSQL contains a ->connect function, which is a mere wrapper around DBI's. Why it can't be found perplexes me: enough reloads later, and database access is working just fine. This doesn't sound like caching whatsoever.
Any ideas? I'm stymied.
-- Morbus Iff ( i put the demon back in codemonkey ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ Spidering Hacks: http://amazon.com/exec/obidos/ASIN/0596005776/disobeycom icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
-- 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
