On 7/22/07, Dustin D. <suppressed> wrote:
I thought I had mod_perl up and running in my development environment, so I pushed the new changes + apache configuration out to my production environment, and immediately began tail -f on the logs. What I noticed was, most of the time, everything was working fine. But it seemed like every few minutes, there would be a burst of the following errors: Can't call method "prepare" on an undefined value at modules//MySQLBroker.pm line 1059.\n
Did you see these in your development environment? How did you make the code live? Did you restart the server or did you use something like Apache::Reload?
What's strange is, when this error would pop up, it would flood 5-10 errors like this in a row, all within the span of a few seconds. Then things would return to normal and I wouldn't get any errors for awhile.
It sounds like your MySQL server is dropping the connections, or else you have multiple processes sharing a connection. Do you do anything during the startup (in httpd.conf or called from httpd.conf) that opens database connections?
(NOTE: for the hostname, I was using localhost for awhile, and decided to use a direct ip in case localhost is actually being resolved, to get rid of one more layer of translation)
Ironically, you actually made it slower there. If you specify 'localhost' or empty string for the server, it will connect using Unix domain sockets instead of TCP. This is a significant performance improvement for simple queries. See the DBD::mysql dcos for more info.
My code around line 1059 in MySQLBroker.pm looks like this:
sub _mysql_exec {
my ($self, $dbcall) = @_;
my @resultsArray;
my $count=0;
my $sth = $self->{_dbh}->prepare("$dbcall");
You shouldn't store a $dbh in your objects like this. Apache::DBI will check that your connection is still good when you try to use it, but only if you call connect(). If you don't, your connection can go stale and get dropped.
Also, on a fairly inconsistent basis, I'm also getting "not a CODE reference" errors.
Which part of the code gives you that?
To me, it just seems like mod_perl is very unreliable and unpredictable. The same code that worked reliably (albeit slow) in the CGI world is now extremely unpredictable in the mod_perl world.
It's 100% predictable. You just don't understand how your code works in a persistent environment yet. Give yourself a little time before you throw in the towel. And ask more questions if you're confused. No need to wait a week and get frustrated before asking for help. - Perrin
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.