You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Issac Goldstand <ma...@beamartyr.net> on 2006/11/19 11:01:25 UTC
JOB [CONTRACT] + Re: Windows + MP2 in a production environment
YES! While it's acceptable for light and smallish applications, I've
never found it to be really usable once you're serving concurrent
connections.
On that note, I have a contract (job) offer for anyone who knows their
way inside Perl (5.8) and mod_perl (2) enough to help troubleshoot a
win32-related crash. In short, once we put heavy load on the server, we
see a crash reported from inside libperl58.dll - my theory is that it's
thread-related, but I don't have the time to look into it properly. If
anyone thinks that they are capable of identifying and fixing the
problem, please email me.
Issac
Foo JH wrote:
> Hello guys,
>
> Just want to get some feedback from people here who use MP2 on Windows
> for their production enviromment. For myself I have done MP2 on both
> FreeBSD and Windows platforms, and it seems to me that the FreeBSD
> combo is more reliable. The Windows version on occasion (but sure to
> happen) will throw out an error, and Apache will restart
> automatically. Does anyone share the same experience?
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Jorge Schrauwen <jo...@gmail.com>.
is this still compatible with the current trunk?
If so maybe it can be reactivated for trunk and 2.2?
>From what i gather from the info it seems interesting enough.
On 11/20/06, Mladen Turk <mt...@apache.org> wrote:
>
> Issac Goldstand wrote:
> >
> > I don't think that the problem is mod_perl, as much as the winnt MPM in
> > Apache2. The bottom line is that if anything goes wrong, you need the
> > singleton child process to recycle itself, and very often in the case of
> > mod_perl that can take a long time.
>
> There is experimental mpm_winxp that I did 2 years ago,
> but there was no real interest, so I didn't develop that
> further.
>
> http://people.apache.org/~mturk/
>
> Regards,
> Mladen
>
--
~Jorge
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Mladen Turk <mt...@apache.org>.
Issac Goldstand wrote:
>
> I don't think that the problem is mod_perl, as much as the winnt MPM in
> Apache2. The bottom line is that if anything goes wrong, you need the
> singleton child process to recycle itself, and very often in the case of
> mod_perl that can take a long time.
There is experimental mpm_winxp that I did 2 years ago,
but there was no real interest, so I didn't develop that
further.
http://people.apache.org/~mturk/
Regards,
Mladen
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Philip M. Gollucci wrote:
> William A. Rowe, Jr. wrote:
>> Keep in mind, using the official build of httpd you have .pdb debug
>> files that can be downloaded that exactly match the .exe/.dll's/.so's
>> that we ship. That means you can -debug- these segfaults.
> Am I able to make these from UNIX ?
> Where can I read about this?
>
> Randy/Steve ?
I do -not- know what sort of debugging symbol tables are emitted from mingw
or cyg toolchains, but VC compile flag /Zi shoves out the symbols into a
compiler database (/Fd directs the output to a particular database name)
and the link flags /debug /opt:ref /incremental:no creates an .exe and
run time symbol database by the same name as the linked file (httpsd.exe
gains httpsd.pdb).
Here's where things get confusing and why devs disable or throw these .pdb
files away. 1 - compiler .pdb's aren't runtime symbol databases (different
formats, even - although both are named .pdb). You would only hang onto
a compiler .pdb that corresponds to a distributed link .lib binary. And
2 - the /Zi flag doesn't inhibit or change the optimization, and 3 - the
link flags /debug /opt:ref /incremental:no only differ from a /release
build by a couple of PE flags that identify the emitted .pdb. Finally,
4 - you must keep the exact .pdb's that correspond to the binaries. You
can't regenerate them reliably, and especially cannot generate them after
the fact with a slightly different version of the compiler.
Think of .exe + .pdb as an unstripped unix pe binary, the symbols in this
case -are- stripped, over to the .pdb. Users don't need the .pdb, but the
original binaries and .pdb file(s) must be present to open a user.dmp crash
file in a debugger, or for Dr Watson to produce truly intelligible output.
If you don't have a .pdb, and the compiler flag /Oy- is given, you can still
unwind the backtrace (with very limited clues). But /O2 (without /Oy-) will
optimize the calling frames - so without a .pdb such backtraces are illegible.
Hope this offers a few clues; I've started to toggle /Oy- always since it
makes a Dr Watson backtrace offer a few clues about a crash without having
to grab the user.dmp file. More hints are here;
http://httpd.apache.org/dev/debugging.html#backtrace-win
See
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Philip M. Gollucci wrote:
> William A. Rowe, Jr. wrote:
>> Keep in mind, using the official build of httpd you have .pdb debug
>> files that can be downloaded that exactly match the .exe/.dll's/.so's
>> that we ship. That means you can -debug- these segfaults.
> Am I able to make these from UNIX ?
> Where can I read about this?
>
> Randy/Steve ?
I do -not- know what sort of debugging symbol tables are emitted from mingw
or cyg toolchains, but VC compile flag /Zi shoves out the symbols into a
compiler database (/Fd directs the output to a particular database name)
and the link flags /debug /opt:ref /incremental:no creates an .exe and
run time symbol database by the same name as the linked file (httpsd.exe
gains httpsd.pdb).
Here's where things get confusing and why devs disable or throw these .pdb
files away. 1 - compiler .pdb's aren't runtime symbol databases (different
formats, even - although both are named .pdb). You would only hang onto
a compiler .pdb that corresponds to a distributed link .lib binary. And
2 - the /Zi flag doesn't inhibit or change the optimization, and 3 - the
link flags /debug /opt:ref /incremental:no only differ from a /release
build by a couple of PE flags that identify the emitted .pdb. Finally,
4 - you must keep the exact .pdb's that correspond to the binaries. You
can't regenerate them reliably, and especially cannot generate them after
the fact with a slightly different version of the compiler.
Think of .exe + .pdb as an unstripped unix pe binary, the symbols in this
case -are- stripped, over to the .pdb. Users don't need the .pdb, but the
original binaries and .pdb file(s) must be present to open a user.dmp crash
file in a debugger, or for Dr Watson to produce truly intelligible output.
If you don't have a .pdb, and the compiler flag /Oy- is given, you can still
unwind the backtrace (with very limited clues). But /O2 (without /Oy-) will
optimize the calling frames - so without a .pdb such backtraces are illegible.
Hope this offers a few clues; I've started to toggle /Oy- always since it
makes a Dr Watson backtrace offer a few clues about a crash without having
to grab the user.dmp file. More hints are here;
http://httpd.apache.org/dev/debugging.html#backtrace-win
See
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
William A. Rowe, Jr. wrote:
> Keep in mind, using the official build of httpd you have .pdb debug
> files that can be downloaded that exactly match the .exe/.dll's/.so's
> that we ship. That means you can -debug- these segfaults.
Am I able to make these from UNIX ?
Where can I read about this?
Randy/Steve ?
> I'd hope that modperl would do the same for their module (and the whole
> bundle if they ship httpd.) They are invaluable. Of course, you also
> need the .pdb file from perl58.dll itself, I'd expect.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
William A. Rowe, Jr. wrote:
> Keep in mind, using the official build of httpd you have .pdb debug
> files that can be downloaded that exactly match the .exe/.dll's/.so's
> that we ship. That means you can -debug- these segfaults.
Am I able to make these from UNIX ?
Where can I read about this?
Randy/Steve ?
> I'd hope that modperl would do the same for their module (and the whole
> bundle if they ship httpd.) They are invaluable. Of course, you also
> need the .pdb file from perl58.dll itself, I'd expect.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Foo JH wrote:
>
> By 'bad code' you're referring to code written by app developers? I
> suspected I fall into that category, but even when I throw in all the
> eval traps, the .dll errors still come to crash (and automatically
> restart) apache.
By bad code, I mean flaws in apr, httpd, modperl, perl applications...
anywhere that brings you a segfault.
Keep in mind, using the official build of httpd you have .pdb debug
files that can be downloaded that exactly match the .exe/.dll's/.so's
that we ship. That means you can -debug- these segfaults.
I'd hope that modperl would do the same for their module (and the whole
bundle if they ship httpd.) They are invaluable. Of course, you also
need the .pdb file from perl58.dll itself, I'd expect.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Foo JH wrote:
>
> By 'bad code' you're referring to code written by app developers? I
> suspected I fall into that category, but even when I throw in all the
> eval traps, the .dll errors still come to crash (and automatically
> restart) apache.
By bad code, I mean flaws in apr, httpd, modperl, perl applications...
anywhere that brings you a segfault.
Keep in mind, using the official build of httpd you have .pdb debug
files that can be downloaded that exactly match the .exe/.dll's/.so's
that we ship. That means you can -debug- these segfaults.
I'd hope that modperl would do the same for their module (and the whole
bundle if they ship httpd.) They are invaluable. Of course, you also
need the .pdb file from perl58.dll itself, I'd expect.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
> As Mladen hints, this was just 'the way it was done' since the Apache 1.3
> MPM was first created. I began to set up more of the structures for having
> parallel running httpd's and Mladen took this one step further with his
> winxp mpm, but the bottom line is that resource sharing just doesn't work
> the same way on windows as unix, and things like interlocking parallel
> writes by two processes to a log file, for example, still need additional
> work to behave without a huge performance hit.
>
> So you are strictly asking if winxp will ever become more tolerant of the
> processes crashing due to bad code?
By 'bad code' you're referring to code written by app developers? I
suspected I fall into that category, but even when I throw in all the
eval traps, the .dll errors still come to crash (and automatically
restart) apache.
I don't mind if performance is hit with the windows implementation of
modperl, since the usage is not exactly ebay load. But having
unpredictable cases of apache restarts - and a windows error message
popping out to state that fact - does give my administrators weak hearts.
I think the general game plan is that developers are able to rely on the
Windows platform for general deployments. The Linux/ FreeBSD alternative
is really when they need extra muscle for the job.
What with Java/ Ruby/ PHP/ .Net already working reliably on Windows,
it's difficult for modperl evangelists to convince their bosses that a
good language/ framework does not need to prove itself on the most
popular OS to date.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
> As Mladen hints, this was just 'the way it was done' since the Apache 1.3
> MPM was first created. I began to set up more of the structures for having
> parallel running httpd's and Mladen took this one step further with his
> winxp mpm, but the bottom line is that resource sharing just doesn't work
> the same way on windows as unix, and things like interlocking parallel
> writes by two processes to a log file, for example, still need additional
> work to behave without a huge performance hit.
>
> So you are strictly asking if winxp will ever become more tolerant of the
> processes crashing due to bad code?
By 'bad code' you're referring to code written by app developers? I
suspected I fall into that category, but even when I throw in all the
eval traps, the .dll errors still come to crash (and automatically
restart) apache.
I don't mind if performance is hit with the windows implementation of
modperl, since the usage is not exactly ebay load. But having
unpredictable cases of apache restarts - and a windows error message
popping out to state that fact - does give my administrators weak hearts.
I think the general game plan is that developers are able to rely on the
Windows platform for general deployments. The Linux/ FreeBSD alternative
is really when they need extra muscle for the job.
What with Java/ Ruby/ PHP/ .Net already working reliably on Windows,
it's difficult for modperl evangelists to convince their bosses that a
good language/ framework does not need to prove itself on the most
popular OS to date.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Issac Goldstand wrote:
> CC-ing to dev@httpd in the hopes that someone (**cough**wrowe?**cough**)
> might shed some deeper insight into why things were/are done the way
> they are, and what, if anything, would be needed to be done to make
> things better.
>
> I don't think that the problem is mod_perl, as much as the winnt MPM in
> Apache2. The bottom line is that if anything goes wrong, you need the
> singleton child process to recycle itself, and very often in the case of
> mod_perl that can take a long time. But the essential problem still
> exists with PHP, mod_python, even theoretically in a minimal vanilla
> httpd install.
As Mladen hints, this was just 'the way it was done' since the Apache 1.3
MPM was first created. I began to set up more of the structures for having
parallel running httpd's and Mladen took this one step further with his
winxp mpm, but the bottom line is that resource sharing just doesn't work
the same way on windows as unix, and things like interlocking parallel
writes by two processes to a log file, for example, still need additional
work to behave without a huge performance hit.
So you are strictly asking if winxp will ever become more tolerant of the
processes crashing due to bad code? Well, the answer is yes, either parallel
running child processes and/or hot standby have always been on the table; if
someone has time to design (as Mladen did with winxp mpm) and enough win folk
have time to review (something that hasn't happened with Mladen's design.)
That will never solve the problem that your dead process just took down dozens
of parallel requests in the process. And no - windows will never perform all
that well with 1 worker/process. If you want a very insecure MPM, it would
be possible to defer the process exit after a fault on one thread (suspending
that thread while the others run out) but this makes root exploits far easier
to design.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Mladen Turk <mt...@apache.org>.
Issac Goldstand wrote:
>
> I don't think that the problem is mod_perl, as much as the winnt MPM in
> Apache2. The bottom line is that if anything goes wrong, you need the
> singleton child process to recycle itself, and very often in the case of
> mod_perl that can take a long time.
There is experimental mpm_winxp that I did 2 years ago,
but there was no real interest, so I didn't develop that
further.
http://people.apache.org/~mturk/
Regards,
Mladen
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Issac Goldstand wrote:
> CC-ing to dev@httpd in the hopes that someone (**cough**wrowe?**cough**)
> might shed some deeper insight into why things were/are done the way
> they are, and what, if anything, would be needed to be done to make
> things better.
>
> I don't think that the problem is mod_perl, as much as the winnt MPM in
> Apache2. The bottom line is that if anything goes wrong, you need the
> singleton child process to recycle itself, and very often in the case of
> mod_perl that can take a long time. But the essential problem still
> exists with PHP, mod_python, even theoretically in a minimal vanilla
> httpd install.
As Mladen hints, this was just 'the way it was done' since the Apache 1.3
MPM was first created. I began to set up more of the structures for having
parallel running httpd's and Mladen took this one step further with his
winxp mpm, but the bottom line is that resource sharing just doesn't work
the same way on windows as unix, and things like interlocking parallel
writes by two processes to a log file, for example, still need additional
work to behave without a huge performance hit.
So you are strictly asking if winxp will ever become more tolerant of the
processes crashing due to bad code? Well, the answer is yes, either parallel
running child processes and/or hot standby have always been on the table; if
someone has time to design (as Mladen did with winxp mpm) and enough win folk
have time to review (something that hasn't happened with Mladen's design.)
That will never solve the problem that your dead process just took down dozens
of parallel requests in the process. And no - windows will never perform all
that well with 1 worker/process. If you want a very insecure MPM, it would
be possible to defer the process exit after a fault on one thread (suspending
that thread while the others run out) but this makes root exploits far easier
to design.
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Issac Goldstand <ma...@beamartyr.net>.
CC-ing to dev@httpd in the hopes that someone (**cough**wrowe?**cough**)
might shed some deeper insight into why things were/are done the way
they are, and what, if anything, would be needed to be done to make
things better.
I don't think that the problem is mod_perl, as much as the winnt MPM in
Apache2. The bottom line is that if anything goes wrong, you need the
singleton child process to recycle itself, and very often in the case of
mod_perl that can take a long time. But the essential problem still
exists with PHP, mod_python, even theoretically in a minimal vanilla
httpd install.
Issac
Foo JH wrote:
> This is a disappointing piece of news. Perl itself is very useful on
> the Windows environment. If modperl cannot be reliably deployed on
> Windows, how can we expect the Windows developers (which form the
> majority of developers) to consider adopting perl/ modperl for the
> enterprise?
>
> I hope we can find people who can testify otherwise...
>
> Issac Goldstand wrote:
>> YES! While it's acceptable for light and smallish applications, I've
>> never found it to be really usable once you're serving concurrent
>> connections.
>>
>> Issac
>>
>> Foo JH wrote:
>>> Hello guys,
>>>
>>> Just want to get some feedback from people here who use MP2 on
>>> Windows for their production enviromment. For myself I have done MP2
>>> on both FreeBSD and Windows platforms, and it seems to me that the
>>> FreeBSD combo is more reliable. The Windows version on occasion (but
>>> sure to happen) will throw out an error, and Apache will restart
>>> automatically. Does anyone share the same experience?
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Issac Goldstand <ma...@beamartyr.net>.
CC-ing to dev@httpd in the hopes that someone (**cough**wrowe?**cough**)
might shed some deeper insight into why things were/are done the way
they are, and what, if anything, would be needed to be done to make
things better.
I don't think that the problem is mod_perl, as much as the winnt MPM in
Apache2. The bottom line is that if anything goes wrong, you need the
singleton child process to recycle itself, and very often in the case of
mod_perl that can take a long time. But the essential problem still
exists with PHP, mod_python, even theoretically in a minimal vanilla
httpd install.
Issac
Foo JH wrote:
> This is a disappointing piece of news. Perl itself is very useful on
> the Windows environment. If modperl cannot be reliably deployed on
> Windows, how can we expect the Windows developers (which form the
> majority of developers) to consider adopting perl/ modperl for the
> enterprise?
>
> I hope we can find people who can testify otherwise...
>
> Issac Goldstand wrote:
>> YES! While it's acceptable for light and smallish applications, I've
>> never found it to be really usable once you're serving concurrent
>> connections.
>>
>> Issac
>>
>> Foo JH wrote:
>>> Hello guys,
>>>
>>> Just want to get some feedback from people here who use MP2 on
>>> Windows for their production enviromment. For myself I have done MP2
>>> on both FreeBSD and Windows platforms, and it seems to me that the
>>> FreeBSD combo is more reliable. The Windows version on occasion (but
>>> sure to happen) will throw out an error, and Apache will restart
>>> automatically. Does anyone share the same experience?
Re: SV: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Foo JH wrote:
> William A. Rowe, Jr. wrote:
>> Foo JH wrote:
>>
>>> Yes! It's really (in)famous! :) The more detailed error message seems to
>>> be captured in the Event Application log instead. I wonder why error.log
>>> wasn't more verbose on this one.
>>
>> Because, once it crashes it's no longer logging?
>>
> Yet it is able to restart itself automatically? I think there may be a
> piece of code that catches the fault. I just don't know if that piece of
> code can still log at that point in time.
Nope - the faulted child process simply dies. The -parent- process is the
one which detects this event and launches a replacement child process.
Look in task manager - and choose to show #threads. One will be running
only a few threads - that's the parent, and one will have dozens or even
hundreds of threads depending on MaxClients.
Re: SV: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
William A. Rowe, Jr. wrote:
> Foo JH wrote:
>
>> Yes! It's really (in)famous! :) The more detailed error message seems to
>> be captured in the Event Application log instead. I wonder why error.log
>> wasn't more verbose on this one.
>>
>
> Because, once it crashes it's no longer logging?
>
Yet it is able to restart itself automatically? I think there may be a
piece of code that catches the fault. I just don't know if that piece of
code can still log at that point in time.
Re: SV: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Foo JH wrote:
> Yes! It's really (in)famous! :) The more detailed error message seems to
> be captured in the Event Application log instead. I wonder why error.log
> wasn't more verbose on this one.
Because, once it crashes it's no longer logging?
Re: SV: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
Henrik Schak Hansen wrote:
> Hi All,
>
> I think we are a lot of windows users experiencing the same problem with mod_perl/apache: "The famous 3221225477 exit status".
> My company will also be willing to donate some money If it will help solving the problem.
Yes! It's really (in)famous! :) The more detailed error message seems to
be captured in the Event Application log instead. I wonder why error.log
wasn't more verbose on this one.
Re: SV: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
> In the list of all modules you are using in your application, are you
> sure that all modules are thread-safe ? If only one is not
> thread-safe, you may encounter an error at a time while running your
> application ?
For my part, I use mainly CPAN libraries. This includes:
HTML::Template
DBI
DBD::ODBC
DBD::MySQL
XML::Simple
Apache::DBI
I suspect DBI may not be thread-safe (at least I don't know how to share
a DBI object across threads), but since I doing connection pooling via
Apache::DBI, I suppose it helps.
The problem with Apache restarting itself, is that it is not predictable
at all. I created a simple app that uses all of the above libraries, and
hit the page 10,000 times. It's still fine. But then again, the test is
overly simplistic...
>
> I'd never found a way to configure apache 2 + mod_perl 2 to work in a
> pre-forked environment on windows. Is there anyone who knows if it's
> possible ?
>
> Stéphane
Re: SV: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Stephane GUIBOUD-RIBAUD <st...@st.com>.
Philip M. Gollucci wrote:
> Its been about 6 years since I've tried anything mod_perl windows
> related, but I recall that some of the startup.pl files of that time
> loaded LibXML and related by default. You might have been loading it and
> just not using it.
The related problem on windows is that mod_perl is running on a
multi-threaded environment (not the case on unix in standard
installation). The example of LibXML should not confused the real problem:
In the list of all modules you are using in your application, are you
sure that all modules are thread-safe ? If only one is not thread-safe,
you may encounter an error at a time while running your application ?
I'd never found a way to configure apache 2 + mod_perl 2 to work in a
pre-forked environment on windows. Is there anyone who knows if it's
possible ?
Stéphane
Re: SV: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Henrik Schak Hansen wrote:
> Hi All,
>
> I think we are a lot of windows users experiencing the same problem with mod_perl/apache: "The famous 3221225477 exit status".
> My company will also be willing to donate some money If it will help solving the problem.
>
> BTW. I don't recall using the LibXML library unless it is used in some of the other modules I use (Template Toolkit).
>
> Best regards
> Henrik Schak Hansen
Its been about 6 years since I've tried anything mod_perl windows
related, but I recall that some of the startup.pl files of that time
loaded LibXML and related by default. You might have been loading it and
just not using it.
--
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/A79997FA F357 0FDD 2301 6296 690F 6A47 D55A 7172 A799 97F
I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.
SV: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Henrik Schak Hansen <hs...@back-bone.dk>.
Hi All,
I think we are a lot of windows users experiencing the same problem with mod_perl/apache: "The famous 3221225477 exit status".
My company will also be willing to donate some money If it will help solving the problem.
BTW. I don't recall using the LibXML library unless it is used in some of the other modules I use (Template Toolkit).
Best regards
Henrik Schak Hansen
-----Oprindelig meddelelse-----
Fra: Foo JH [mailto:jhfoo-ml@extracktor.com]
Sendt: 21. november 2006 08:57
Til: Stephane GUIBOUD-RIBAUD
Cc: mod_perl
Emne: Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Hey Stephane,
Thanks for zeroing in on the problem libraries. I don't remember using LibXML, but I'll see if I can replicate the problem as well, in a simplified model.
Stephane GUIBOUD-RIBAUD wrote:
> I had a similar issue one year ago with mod_perl 2.0.0-RC4 and perl
> 5.6.1 (same issue with perl 5.8).
>
> The problem was due to the use of LibXML (which is the fastest xml
> parsing library I found to parse large XML files) with mod_perl and
> apache in a multi-threaded environment. I also had some issues with
> SOAP-Lite module in my environment.
>
> I had to go back to a CGI application to solve this problem, but I
> don't have a highly loaded server at this time.
>
> Stéphane
>
> Issac Goldstand wrote:
>> We were originally using 5.8.3, but reproduced the problem with both
>> activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM
>> repository) as well as our own built perl + mod_perl 2.0.3-rc2
>>
>> Randy Kobes wrote:
>>> On Sun, 19 Nov 2006, Foo JH wrote:
>>>
>>>> Issac Goldstand wrote:
>>>>> YES! While it's acceptable for light and smallish applications,
>>>>> I've never found it to be really usable once you're serving
>>>>> concurrent connections.
>>>>>
>>>>> On that note, I have a contract (job) offer for anyone who knows
>>>>> their way inside Perl (5.8) and mod_perl (2) enough to help
>>>>> troubleshoot a win32-related crash. In short, once we put heavy
>>>>> load on the server, we see a crash reported from inside
>>>>> libperl58.dll - my theory is that it's thread-related, but I don't
>>>>> have the time to look into it properly. If anyone thinks that
>>>>> they are capable of identifying and fixing the problem, please email me.
>>> What version of perl are you using? There were some threads-related
>>> fixes introduced in perl-5.8.8 that solved some problems with
>>> earlier versions.
>>>
>>
-------
[Denne E-mail blev scannet for virus af Declude Virus] [This E-mail was scanned for viruses by Declude Virus]
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
Hey Stephane,
Thanks for zeroing in on the problem libraries. I don't remember using
LibXML, but I'll see if I can replicate the problem as well, in a
simplified model.
Stephane GUIBOUD-RIBAUD wrote:
> I had a similar issue one year ago with mod_perl 2.0.0-RC4 and perl
> 5.6.1 (same issue with perl 5.8).
>
> The problem was due to the use of LibXML (which is the fastest xml
> parsing library I found to parse large XML files) with mod_perl and
> apache in a multi-threaded environment. I also had some issues with
> SOAP-Lite module in my environment.
>
> I had to go back to a CGI application to solve this problem, but I
> don't have a highly loaded server at this time.
>
> Stéphane
>
> Issac Goldstand wrote:
>> We were originally using 5.8.3, but reproduced the problem with both
>> activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM repository)
>> as well as our own built perl + mod_perl 2.0.3-rc2
>>
>> Randy Kobes wrote:
>>> On Sun, 19 Nov 2006, Foo JH wrote:
>>>
>>>> Issac Goldstand wrote:
>>>>> YES! While it's acceptable for light and smallish applications, I've
>>>>> never found it to be really usable once you're serving concurrent
>>>>> connections.
>>>>>
>>>>> On that note, I have a contract (job) offer for anyone who knows
>>>>> their way inside Perl (5.8) and mod_perl (2) enough to help
>>>>> troubleshoot a win32-related crash. In short, once we put heavy load
>>>>> on the server, we see a crash reported from inside libperl58.dll - my
>>>>> theory is that it's thread-related, but I don't have the time to look
>>>>> into it properly. If anyone thinks that they are capable of
>>>>> identifying and fixing the problem, please email me.
>>> What version of perl are you using? There were some
>>> threads-related fixes introduced in perl-5.8.8 that
>>> solved some problems with earlier versions.
>>>
>>
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Stephane GUIBOUD-RIBAUD <st...@st.com>.
I had a similar issue one year ago with mod_perl 2.0.0-RC4 and perl
5.6.1 (same issue with perl 5.8).
The problem was due to the use of LibXML (which is the fastest xml
parsing library I found to parse large XML files) with mod_perl and
apache in a multi-threaded environment. I also had some issues with
SOAP-Lite module in my environment.
I had to go back to a CGI application to solve this problem, but I don't
have a highly loaded server at this time.
Stéphane
Issac Goldstand wrote:
> We were originally using 5.8.3, but reproduced the problem with both
> activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM repository)
> as well as our own built perl + mod_perl 2.0.3-rc2
>
> Randy Kobes wrote:
>> On Sun, 19 Nov 2006, Foo JH wrote:
>>
>>> Issac Goldstand wrote:
>>>> YES! While it's acceptable for light and smallish applications, I've
>>>> never found it to be really usable once you're serving concurrent
>>>> connections.
>>>>
>>>> On that note, I have a contract (job) offer for anyone who knows
>>>> their way inside Perl (5.8) and mod_perl (2) enough to help
>>>> troubleshoot a win32-related crash. In short, once we put heavy load
>>>> on the server, we see a crash reported from inside libperl58.dll - my
>>>> theory is that it's thread-related, but I don't have the time to look
>>>> into it properly. If anyone thinks that they are capable of
>>>> identifying and fixing the problem, please email me.
>> What version of perl are you using? There were some
>> threads-related fixes introduced in perl-5.8.8 that
>> solved some problems with earlier versions.
>>
>
SV: Windows + MP2 in a production environment
Posted by Henrik Schak Hansen <hs...@back-bone.dk>.
Not being an C/C++ programmer.... does this mean that the bug has been
found and solved?
Is it in mod_perl or Perl the bug is?
henrik
-----Oprindelig meddelelse-----
Fra: Issac Goldstand [mailto:margol@beamartyr.net]
Sendt: 22. november 2006 08:41
Til: mod_perl
Cc: Randy Kobes; Foo JH; Eyal Mandelzweig
Emne: Re: Windows + MP2 in a production environment
It took me a while to get everything together, and I was involved in a
minor pile-up car accident (I'm fine - car needs body work) so this got
delayed more than I originally intended. Apologies to people who were
standing by with test environments to try to work this out.
Getting to the point (quoting this from the developer who was in charge
of this issue):
--- BEGIN QUOTE ---
The crash occurs on computer with Microsoft Windows Server 2003 Standard
Edition Service Pack 1. With dual Intel XEON HyperThreading CPU 3.00 GHZ
and 3.00 GB RAM
We originally found the bug when We used Apache 2.0.2 ,Mod_perl
1.99-dev,Perl 5.8.3, and also the bug still occurred when we upgraded
the server to Apache 2.2.3,Mod_perl 2.0.3 RC2,Perl 5.8.8
The event log message is "Faulting application httpd.exe version
2.2.3.0, faulting module perl58.dll version 0.0.0.0, fault address
0x0015bdb4"
The configuration of the server:
PerlInterpMax 10 and more
# Creates 7 interpreter threads when Apache starts up (def 3)
PerlInterpStart 7 and up # Leave a maximum of 7 spare threads (not used
threads) PerlInterpMaxSpare 7 and up.
Httpd.conf :
ThreadsPerChild 250
MaxRequestsPerChild 0
After compiling the perl with debug symbols and running it using the
Windbg application I got the following stack trace:
perl58!VMem::Free+0x5e
perl58!CPerlHost::FreeShared+0x2a
perl58!PerlMemSharedFree+0x1a
perl58!Perl_newCONSTUB+0x28a
perl58!S_cv_clone2+0x8ce
perl58!Perl_cv_clone+0x1a
perl58!Perl_pp_anoncode+0x46
perl58!Perl_runops_debug+0x18f
perl58!S_call_body+0x52
perl58!Perl_call_sv+0x703
perl58!S_call_list_body+0x57
perl58!Perl_call_list+0x18a
perl58!Perl_newATTRSUB+0x1306
perl58!Perl_utilize+0x4e3
perl58!Perl_yyparse+0x1543
perl58!S_doeval+0x3a8
perl58!Perl_pp_require+0x19c9
mod_perl!modperl_pp_require+0xd
perl58!Perl_runops_debug+0x18f
perl58!S_call_body+0x52
In order to avoid the problem I used the __try and __catch which are
used in Microsoft win32 applications changing :
inline void FreeShared(void* ptr)
{
GetLockShared();
__try{
m_pVMemShared->Free(ptr);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
}
FreeLockShared();
};
Located in win32\perlhost.h file.
The crash occurs in VMem::free function probably during freeing of the
block of memory there.
--- END QUOTE ---
Issac
Issac Goldstand wrote:
> Unfortunately, so far not yet... We haven't been able to get it to
> reproduce on a test machine yet - the setup on the problematic machine
> is Dual hyperthreading 3.0Ghz Xeons with 3GB RAM, running Win2003
> Server SP1.
> The closest we've got to match that setup is with a dual core
> Pentium-D
> 3.4 Ghz machine with XP SP2, or a VMWare VM with 2 virtual processors
> (host machine is a Pentium 4-HT 2.8 Ghz machine) with 1.2GB RAM
> running
> win2003 SP1.
>
> I'll post the exact error messages, as well as a workaround that
> someone put together (definitely workaround and not fix - he just
> wraps the deepest crashing subroutine in a Visual C __try {} block, as
> I understand; I haven't seen it myself yet), as soon as I can.
>
> Issac
>
> Randy Kobes wrote:
>> On Sun, 19 Nov 2006, Issac Goldstand wrote:
>>
>>> Foo JH wrote:
>>>> Issac Goldstand wrote:
>>>>> We were originally using 5.8.3, but reproduced the problem with
>>>>> both activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM
>>>>> repository)
>>>>> as well as our own built perl + mod_perl 2.0.3-rc2
>>>>>
>>>> I wonder if modperl on apache 2.2 will resolve this issue...
>>
>>> We're using 2.2.3 - Upgrading everything to the latest stable
>>> versions was the first thing we tried.
>>
>> Is it possible to provide a minimal script that illustrates the
>> problem? There's some people on the list that have threads-enabled
>> unix setups; it would be interesting to see if it's also a problem
>> there.
>>
>
-------
[Denne E-mail blev scannet for virus af Declude Virus] [This E-mail was
scanned for viruses by Declude Virus]
Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
Sorry to hear about your accident. Glad you're OK.
Your analysis seems to point to Perl being unable to free memory blocks
in Windows (will it happen in Linux as well?). Appending to my
experience, this problem happens when there is a huge block of memory to
release.
I'm not much of a C/C++ developer, so my question is: for those of us
who depend on the ActivePerl track for modperl, is there a workaround we
can use?
You should give your developer a pat on the back for coming up with such
an ingenious workaround!
Issac Goldstand wrote:
> It took me a while to get everything together, and I was involved in a
> minor pile-up car accident (I'm fine - car needs body work) so this got
> delayed more than I originally intended. Apologies to people who were
> standing by with test environments to try to work this out.
>
> Getting to the point (quoting this from the developer who was in charge
> of this issue):
> --- BEGIN QUOTE ---
> The crash occurs on computer with Microsoft Windows Server 2003 Standard
> Edition Service Pack 1. With dual Intel XEON HyperThreading CPU 3.00 GHZ
> and 3.00 GB RAM
>
> We originally found the bug when We used Apache 2.0.2 ,Mod_perl
> 1.99-dev,Perl 5.8.3, and also the bug still occurred when we upgraded
> the server to Apache 2.2.3,Mod_perl 2.0.3 RC2,Perl 5.8.8
>
> The event log message is "Faulting application httpd.exe version
> 2.2.3.0, faulting module perl58.dll version 0.0.0.0, fault address
> 0x0015bdb4"
>
> The configuration of the server:
> PerlInterpMax 10 and more
> # Creates 7 interpreter threads when Apache starts up (def 3)
> PerlInterpStart 7 and up
> # Leave a maximum of 7 spare threads (not used threads)
> PerlInterpMaxSpare 7 and up.
> Httpd.conf :
> ThreadsPerChild 250
> MaxRequestsPerChild 0
>
> After compiling the perl with debug symbols and running it using the
> Windbg application I got the following stack trace:
> perl58!VMem::Free+0x5e
> perl58!CPerlHost::FreeShared+0x2a
> perl58!PerlMemSharedFree+0x1a
> perl58!Perl_newCONSTUB+0x28a
> perl58!S_cv_clone2+0x8ce
> perl58!Perl_cv_clone+0x1a
> perl58!Perl_pp_anoncode+0x46
> perl58!Perl_runops_debug+0x18f
> perl58!S_call_body+0x52
> perl58!Perl_call_sv+0x703
> perl58!S_call_list_body+0x57
> perl58!Perl_call_list+0x18a
> perl58!Perl_newATTRSUB+0x1306
> perl58!Perl_utilize+0x4e3
> perl58!Perl_yyparse+0x1543
> perl58!S_doeval+0x3a8
> perl58!Perl_pp_require+0x19c9
> mod_perl!modperl_pp_require+0xd
> perl58!Perl_runops_debug+0x18f
> perl58!S_call_body+0x52
>
> In order to avoid the problem I used the __try and __catch which are
> used in Microsoft win32 applications changing :
> inline void FreeShared(void* ptr)
> {
> GetLockShared();
> __try{
> m_pVMemShared->Free(ptr);
> }
> __except(EXCEPTION_EXECUTE_HANDLER)
> {
> }
> FreeLockShared();
> };
> Located in win32\perlhost.h file.
> The crash occurs in VMem::free function probably during freeing of the
> block of memory there.
>
> --- END QUOTE ---
>
> Issac
>
>
> Issac Goldstand wrote:
>
>> Unfortunately, so far not yet... We haven't been able to get it to
>> reproduce on a test machine yet - the setup on the problematic machine
>> is Dual hyperthreading 3.0Ghz Xeons with 3GB RAM, running Win2003 Server
>> SP1.
>> The closest we've got to match that setup is with a dual core Pentium-D
>> 3.4 Ghz machine with XP SP2, or a VMWare VM with 2 virtual processors
>> (host machine is a Pentium 4-HT 2.8 Ghz machine) with 1.2GB RAM running
>> win2003 SP1.
>>
>> I'll post the exact error messages, as well as a workaround that someone
>> put together (definitely workaround and not fix - he just wraps the
>> deepest crashing subroutine in a Visual C __try {} block, as I
>> understand; I haven't seen it myself yet), as soon as I can.
>>
>> Issac
>>
>> Randy Kobes wrote:
>>
>>> On Sun, 19 Nov 2006, Issac Goldstand wrote:
>>>
>>>
>>>> Foo JH wrote:
>>>>
>>>>> Issac Goldstand wrote:
>>>>>
>>>>>> We were originally using 5.8.3, but reproduced the problem with both
>>>>>> activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM
>>>>>> repository)
>>>>>> as well as our own built perl + mod_perl 2.0.3-rc2
>>>>>>
>>>>>>
>>>>> I wonder if modperl on apache 2.2 will resolve this issue...
>>>>>
>>>> We're using 2.2.3 - Upgrading everything to the latest stable versions
>>>> was the first thing we tried.
>>>>
>>> Is it possible to provide a minimal script that illustrates
>>> the problem? There's some people on the list that have
>>> threads-enabled unix setups; it would be interesting to
>>> see if it's also a problem there.
>>>
>>>
Re: Windows + MP2 in a production environment
Posted by Issac Goldstand <ma...@beamartyr.net>.
It took me a while to get everything together, and I was involved in a
minor pile-up car accident (I'm fine - car needs body work) so this got
delayed more than I originally intended. Apologies to people who were
standing by with test environments to try to work this out.
Getting to the point (quoting this from the developer who was in charge
of this issue):
--- BEGIN QUOTE ---
The crash occurs on computer with Microsoft Windows Server 2003 Standard
Edition Service Pack 1. With dual Intel XEON HyperThreading CPU 3.00 GHZ
and 3.00 GB RAM
We originally found the bug when We used Apache 2.0.2 ,Mod_perl
1.99-dev,Perl 5.8.3, and also the bug still occurred when we upgraded
the server to Apache 2.2.3,Mod_perl 2.0.3 RC2,Perl 5.8.8
The event log message is "Faulting application httpd.exe version
2.2.3.0, faulting module perl58.dll version 0.0.0.0, fault address
0x0015bdb4"
The configuration of the server:
PerlInterpMax 10 and more
# Creates 7 interpreter threads when Apache starts up (def 3)
PerlInterpStart 7 and up
# Leave a maximum of 7 spare threads (not used threads)
PerlInterpMaxSpare 7 and up.
Httpd.conf :
ThreadsPerChild 250
MaxRequestsPerChild 0
After compiling the perl with debug symbols and running it using the
Windbg application I got the following stack trace:
perl58!VMem::Free+0x5e
perl58!CPerlHost::FreeShared+0x2a
perl58!PerlMemSharedFree+0x1a
perl58!Perl_newCONSTUB+0x28a
perl58!S_cv_clone2+0x8ce
perl58!Perl_cv_clone+0x1a
perl58!Perl_pp_anoncode+0x46
perl58!Perl_runops_debug+0x18f
perl58!S_call_body+0x52
perl58!Perl_call_sv+0x703
perl58!S_call_list_body+0x57
perl58!Perl_call_list+0x18a
perl58!Perl_newATTRSUB+0x1306
perl58!Perl_utilize+0x4e3
perl58!Perl_yyparse+0x1543
perl58!S_doeval+0x3a8
perl58!Perl_pp_require+0x19c9
mod_perl!modperl_pp_require+0xd
perl58!Perl_runops_debug+0x18f
perl58!S_call_body+0x52
In order to avoid the problem I used the __try and __catch which are
used in Microsoft win32 applications changing :
inline void FreeShared(void* ptr)
{
GetLockShared();
__try{
m_pVMemShared->Free(ptr);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
}
FreeLockShared();
};
Located in win32\perlhost.h file.
The crash occurs in VMem::free function probably during freeing of the
block of memory there.
--- END QUOTE ---
Issac
Issac Goldstand wrote:
> Unfortunately, so far not yet... We haven't been able to get it to
> reproduce on a test machine yet - the setup on the problematic machine
> is Dual hyperthreading 3.0Ghz Xeons with 3GB RAM, running Win2003 Server
> SP1.
> The closest we've got to match that setup is with a dual core Pentium-D
> 3.4 Ghz machine with XP SP2, or a VMWare VM with 2 virtual processors
> (host machine is a Pentium 4-HT 2.8 Ghz machine) with 1.2GB RAM running
> win2003 SP1.
>
> I'll post the exact error messages, as well as a workaround that someone
> put together (definitely workaround and not fix - he just wraps the
> deepest crashing subroutine in a Visual C __try {} block, as I
> understand; I haven't seen it myself yet), as soon as I can.
>
> Issac
>
> Randy Kobes wrote:
>> On Sun, 19 Nov 2006, Issac Goldstand wrote:
>>
>>> Foo JH wrote:
>>>> Issac Goldstand wrote:
>>>>> We were originally using 5.8.3, but reproduced the problem with both
>>>>> activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM
>>>>> repository)
>>>>> as well as our own built perl + mod_perl 2.0.3-rc2
>>>>>
>>>> I wonder if modperl on apache 2.2 will resolve this issue...
>>
>>> We're using 2.2.3 - Upgrading everything to the latest stable versions
>>> was the first thing we tried.
>>
>> Is it possible to provide a minimal script that illustrates
>> the problem? There's some people on the list that have
>> threads-enabled unix setups; it would be interesting to
>> see if it's also a problem there.
>>
>
Re: Windows + MP2 in a production environment
Posted by Issac Goldstand <ma...@beamartyr.net>.
Unfortunately, so far not yet... We haven't been able to get it to
reproduce on a test machine yet - the setup on the problematic machine
is Dual hyperthreading 3.0Ghz Xeons with 3GB RAM, running Win2003 Server
SP1.
The closest we've got to match that setup is with a dual core Pentium-D
3.4 Ghz machine with XP SP2, or a VMWare VM with 2 virtual processors
(host machine is a Pentium 4-HT 2.8 Ghz machine) with 1.2GB RAM running
win2003 SP1.
I'll post the exact error messages, as well as a workaround that someone
put together (definitely workaround and not fix - he just wraps the
deepest crashing subroutine in a Visual C __try {} block, as I
understand; I haven't seen it myself yet), as soon as I can.
Issac
Randy Kobes wrote:
> On Sun, 19 Nov 2006, Issac Goldstand wrote:
>
>> Foo JH wrote:
>>> Issac Goldstand wrote:
>>>> We were originally using 5.8.3, but reproduced the problem with both
>>>> activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM
>>>> repository)
>>>> as well as our own built perl + mod_perl 2.0.3-rc2
>>>>
>>> I wonder if modperl on apache 2.2 will resolve this issue...
>
>> We're using 2.2.3 - Upgrading everything to the latest stable versions
>> was the first thing we tried.
>
> Is it possible to provide a minimal script that illustrates
> the problem? There's some people on the list that have
> threads-enabled unix setups; it would be interesting to
> see if it's also a problem there.
>
Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
I have just set up a 2.2.3 + 5.8.8 on a test server. Will see if i can
create the minimal-script app that will produce the same problem.
Issac, what was the error message as reported on your Windows events
(application) log?
Randy Kobes wrote:
> On Sun, 19 Nov 2006, Issac Goldstand wrote:
>
>> Foo JH wrote:
>>> Issac Goldstand wrote:
>>>> We were originally using 5.8.3, but reproduced the problem with both
>>>> activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM
>>>> repository)
>>>> as well as our own built perl + mod_perl 2.0.3-rc2
>>>>
>>> I wonder if modperl on apache 2.2 will resolve this issue...
>
>> We're using 2.2.3 - Upgrading everything to the latest stable versions
>> was the first thing we tried.
>
> Is it possible to provide a minimal script that illustrates
> the problem? There's some people on the list that have
> threads-enabled unix setups; it would be interesting to
> see if it's also a problem there.
>
Re: Windows + MP2 in a production environment
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 19 Nov 2006, Issac Goldstand wrote:
> Foo JH wrote:
>> Issac Goldstand wrote:
>>> We were originally using 5.8.3, but reproduced the problem with both
>>> activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM repository)
>>> as well as our own built perl + mod_perl 2.0.3-rc2
>>>
>> I wonder if modperl on apache 2.2 will resolve this issue...
> We're using 2.2.3 - Upgrading everything to the latest stable versions
> was the first thing we tried.
Is it possible to provide a minimal script that illustrates
the problem? There's some people on the list that have
threads-enabled unix setups; it would be interesting to
see if it's also a problem there.
--
best regards,
Randy
Re: Windows + MP2 in a production environment
Posted by Issac Goldstand <ma...@beamartyr.net>.
We're using 2.2.3 - Upgrading everything to the latest stable versions
was the first thing we tried.
Issac
Foo JH wrote:
> Issac Goldstand wrote:
>> We were originally using 5.8.3, but reproduced the problem with both
>> activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM repository)
>> as well as our own built perl + mod_perl 2.0.3-rc2
>>
> I wonder if modperl on apache 2.2 will resolve this issue...
Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
Issac Goldstand wrote:
> We were originally using 5.8.3, but reproduced the problem with both
> activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM repository)
> as well as our own built perl + mod_perl 2.0.3-rc2
>
I wonder if modperl on apache 2.2 will resolve this issue...
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Issac Goldstand <ma...@beamartyr.net>.
We were originally using 5.8.3, but reproduced the problem with both
activeperl 5.8.8.819 with mod_perl-2.0.3-dev (from your PPM repository)
as well as our own built perl + mod_perl 2.0.3-rc2
Randy Kobes wrote:
> On Sun, 19 Nov 2006, Foo JH wrote:
>
>> Issac Goldstand wrote:
>>> YES! While it's acceptable for light and smallish applications, I've
>>> never found it to be really usable once you're serving concurrent
>>> connections.
>>>
>>> On that note, I have a contract (job) offer for anyone who knows
>>> their way inside Perl (5.8) and mod_perl (2) enough to help
>>> troubleshoot a win32-related crash. In short, once we put heavy load
>>> on the server, we see a crash reported from inside libperl58.dll - my
>>> theory is that it's thread-related, but I don't have the time to look
>>> into it properly. If anyone thinks that they are capable of
>>> identifying and fixing the problem, please email me.
>
> What version of perl are you using? There were some
> threads-related fixes introduced in perl-5.8.8 that
> solved some problems with earlier versions.
>
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 19 Nov 2006, Foo JH wrote:
> Issac Goldstand wrote:
>> YES! While it's acceptable for light and smallish applications, I've never
>> found it to be really usable once you're serving concurrent connections.
>>
>> On that note, I have a contract (job) offer for anyone who knows their way
>> inside Perl (5.8) and mod_perl (2) enough to help troubleshoot a
>> win32-related crash. In short, once we put heavy load on the server, we
>> see a crash reported from inside libperl58.dll - my theory is that it's
>> thread-related, but I don't have the time to look into it properly. If
>> anyone thinks that they are capable of identifying and fixing the problem,
>> please email me.
What version of perl are you using? There were some
threads-related fixes introduced in perl-5.8.8 that
solved some problems with earlier versions.
--
best regards,
Randy Kobes
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
This is a disappointing piece of news. Perl itself is very useful on the
Windows environment. If modperl cannot be reliably deployed on Windows,
how can we expect the Windows developers (which form the majority of
developers) to consider adopting perl/ modperl for the enterprise?
I hope we can find people who can testify otherwise...
Issac Goldstand wrote:
> YES! While it's acceptable for light and smallish applications, I've
> never found it to be really usable once you're serving concurrent
> connections.
>
> On that note, I have a contract (job) offer for anyone who knows their
> way inside Perl (5.8) and mod_perl (2) enough to help troubleshoot a
> win32-related crash. In short, once we put heavy load on the server,
> we see a crash reported from inside libperl58.dll - my theory is that
> it's thread-related, but I don't have the time to look into it
> properly. If anyone thinks that they are capable of identifying and
> fixing the problem, please email me.
>
> Issac
>
> Foo JH wrote:
>> Hello guys,
>>
>> Just want to get some feedback from people here who use MP2 on
>> Windows for their production enviromment. For myself I have done MP2
>> on both FreeBSD and Windows platforms, and it seems to me that the
>> FreeBSD combo is more reliable. The Windows version on occasion (but
>> sure to happen) will throw out an error, and Apache will restart
>> automatically. Does anyone share the same experience?
Re: JOB [CONTRACT] + Re: Windows + MP2 in a production environment
Posted by Foo JH <jh...@extracktor.com>.
Why don't you post the error message here, and see if anyone has seen it
before?
Issac Goldstand wrote:
> YES! While it's acceptable for light and smallish applications, I've
> never found it to be really usable once you're serving concurrent
> connections.
>
> On that note, I have a contract (job) offer for anyone who knows their
> way inside Perl (5.8) and mod_perl (2) enough to help troubleshoot a
> win32-related crash. In short, once we put heavy load on the server,
> we see a crash reported from inside libperl58.dll - my theory is that
> it's thread-related, but I don't have the time to look into it
> properly. If anyone thinks that they are capable of identifying and
> fixing the problem, please email me.
>
> Issac
>
> Foo JH wrote:
>> Hello guys,
>>
>> Just want to get some feedback from people here who use MP2 on
>> Windows for their production enviromment. For myself I have done MP2
>> on both FreeBSD and Windows platforms, and it seems to me that the
>> FreeBSD combo is more reliable. The Windows version on occasion (but
>> sure to happen) will throw out an error, and Apache will restart
>> automatically. Does anyone share the same experience?