perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Mehling <>
Subject Re: [mp2] Win32 apache2 "Restarting" under load
Date Sat, 04 Dec 2004 01:18:35 GMT
On Thu, 02 Dec 2004 16:57:56 -0500, Stas Bekman <> wrote:
> It's always fun with win32, which never gives proper error messages.

"Fun" is one way to describe Win32.  :-)
> I'd start with figuring out what 3221226324 means. Ask on the apache users
> list? This is a generic Apache message, so it's not on our ground.

> It gets the message a few lines above, by calling
>          if (!GetExitCodeProcess(event_handles[CHILD_HANDLE], &exitcode)) {
> Once you figure out what that number means you will hopefully know the
> cause of the process exit.

An Apache developer told me "the GetExitCodeProcess error just gets
the return val from mod_perl".  I'm not exactly sure how we can be
sure mod_perl is the module that's freaking out? Our setup is pretty
stripped down at this point...  mod_perl is the only non-core module
loaded up and I've removed a lot of unused core modules for testing.

It also appears that if I throttle back jMeter, Apache doesn't restart
itself.  At least as of yet. Today I was able to place some decent
load on the server and apache hasn't restarted itself at all.

Perhaps we were simply overwhelming Apache on this hardware/platform...

> > Everything looked clean.  We couldn't find any reason to believe 
> > any of the modules weren't thread safe.

> Looks clean? You mean you read through the XS and C code? Can you please
> share how did you come up with that conclusion? (I'd love to learn how to
> do that)

Heh.  Fair enough.  I should have been more clear:  I spent the better
part of a day looking at the documentation, change logs, and release
notes for the modules mentioned above.  I also searched for discussion
of these libs on the various mail list archives for any talk of thread
safety.  I was able to determine that either a) the module developer
was claiming thread-safety OR b) no one was complaining that they
weren't thread-safe.  Probably not conclusive...

Nope, I didn't look through ALL related XS or C code.  Sorry.  :-)
> I'd also suggest to get rid of these errors:
> > [Tue Nov 23 11:30:47 2004] [error] Can't coerce array into hash at (null) line 589.\n

> It's quite possible that those are related. Add:
> use Carp;

These "Can't coerce" errors don't always appear when Apache restarts
itself, so I don't know which is a symptom of the other or if they are
just two unrelated issues.  Carp returns the following chunk:

 Can't coerce array into hash at (null) line 589.
        DBI::__ANON__() called at C:/services/Perl/site/lib/ line 662
        DBI::connect('DBI', 'dbi:ODBC:cat_prod', 'cat', 'LEE181',
'HASH(0x14e3ff4)') called at
C:/inetpub/webroots/catalyst/cgi/tools/ line 11
called at C:/services/Perl/site/lib/Apache2/ModPerl/
line 202
        eval {...} called at
C:/services/Perl/site/lib/Apache2/ModPerl/ line 202
called at C:/services/Perl/site/lib/Apache2/ModPerl/
line 168
called at C:/services/Perl/site/lib/Apache2/ModPerl/ line
'Apache::RequestRec=SCALAR(0x9ba418)') called at -e line 0
        eval {...} called at -e line 0

I couldn't find much info on the DBI lists.  One suggestion was to
turn tracing on, which I did, but because the error happens so
infrequently and the trace outputs so much data, I haven't been able
to find anything useful.

Regardless of load, this "Can't coerce array in hash" error continues
to come up -- intermittently.

Thanks for your help, Ben

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message