perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [mp2] Win32 apache2 "Restarting" under load
Date Sat, 04 Dec 2004 04:22:40 GMT
Ben Mehling wrote:
> 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 think windows CD should come bundled with 10 years supply of free milk.

>>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?

Neither do I.

Unfortunately if you ask a question on the Apache list and ever mention 
mod_perl, it'll be either ignored or the blame put on mod_perl. That's a 
sad truth.

This is of course not to say that mod_perl never was a problem.

> 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.

Any chance you could try the same exercise on a unix machine with worker 
mpm, and hopefully the diagnostics will be somewhat more helpful? 
(Assuming that the same issue will be encountered).

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

Everything and anything is possible. Without being able to reproduce the 
problem or at least know the cause we can't do much.

>>>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.  :-)

Another sad truth is that most modules are not run in the threaded 
environment, that's the main reason why you can find bug reports.

I'll give you a simple technique how to know for sure whether a given 
Perl/XS module is *not* thread-safe. grep its unpacked source for the 
CLONE function. If it doesn't have one, it's not thread-safe. 100%!

That reminds me that I need to write an article explaining how to use 
CLONE. For now see the docs in:
http://apache.org/~stas/Example-CLONE-0.02.tar.gz

>>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

> 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',

So that comes from DBI, check what it does at line 662 and 589 in DBI.pm.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message