Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of bmehling@gmail.com designates
 64.233.170.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=Nu0UVvkrA5RvikT/2RFF6eBO/ixsIAYANlOlfVu0lZ19ND9nvw20Q0q1yaCQuijPqjJhpzMVcCLJj2JNxOP4qhE8ORMIvIPMX9gHZG8hCknAYzorsM8hnQ1M0M5lU2MjZxcGBxTmiwHLwuLkAaYgfqZxVyLzSvblxqCHCRQIkuM=
Message-ID: <24ba2c1504120317187d0222b1@mail.gmail.com>
Date: Fri, 3 Dec 2004 17:18:35 -0800
From: Ben Mehling <bmehling@gmail.com>
Reply-To: Ben Mehling <bmehling@gmail.com>
To: dev@perl.apache.org
Subject: Re: [mp2] Win32 apache2 "Restarting" under load
In-Reply-To: <41AF8FE4.2080609@stason.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <24ba2c1504113016557e90fc41@mail.gmail.com>
	 <24ba2c15041202133111f658c7@mail.gmail.com>
	 <41AF8FE4.2080609@stason.org>

On Thu, 02 Dec 2004 16:57:56 -0500, Stas Bekman <stas@stason.org> 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;
<snip>

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/DBI.pm line 662
        DBI::connect('DBI', 'dbi:ODBC:cat_prod', 'cat', 'LEE181',
'HASH(0x14e3ff4)') called at
C:/inetpub/webroots/catalyst/cgi/tools/test.cat line 11
        ModPerl::ROOT::ModPerl::Registry::C_3a_inetpub_webroots_catalyst_cgi_tools_test_2ecat::handler('Apache::RequestRec=SCALAR(0x9ba418)')
called at C:/services/Perl/site/lib/Apache2/ModPerl/RegistryCooker.pm
line 202
        eval {...} called at
C:/services/Perl/site/lib/Apache2/ModPerl/RegistryCooker.pm line 202
        ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0x14e40cc)')
called at C:/services/Perl/site/lib/Apache2/ModPerl/RegistryCooker.pm
line 168
        ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0x14e40cc)')
called at C:/services/Perl/site/lib/Apache2/ModPerl/Registry.pm line
30
        ModPerl::Registry::handler('ModPerl::Registry',
'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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org