RE: Content-Type not working on MSIE
Greetings. [...] The issue: The simplest script I can't think of doesn't work. my $r = shift; $r-send_http_header(text/plain); $r-print(hello world); When I try to access the script, my MSIE 6.0 prompts for download when it should simple print the hello world string. Isn't it? [...] Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET /perl/test.pl HTTP/1.0 [...] What I'm doing wrong?? I do not think it is you. But, I have observed that IE sometimes tries to outfox Content-type when the extension of the url maps to one of the locally registered file types. Therefore, if perl (AS) is installed on the client machine, IE will disregard Content-type in favor of the local file association. If this is the case, then changing the extension from .pl to (nothing) should give you the expected result, as would requesting /perl/test.pl?foo=bar instead than /perl/test.pl. As an aside, if anyone on the list knows of ways to defang this really annoying IE behavior, I would be most interested in knowing about it Cheers, alf
RE: [OT?] Win32 permissions puzzler
Greetings. I am afraid this is rapidly becoming less than relevant, however.. -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] [...] You have to declare variables as globals before using them. Agreed Even the imported ones. That's a pure perl issue. Please proceed to the perl lists/groups/monks for further discussion. This is a bit of a surprise the following, in fact, runs just fine: --Foo.pm-- package Foo; use strict; use warnings; require Exporter; our @ISA = qw(Exporter); our @EXPORT_OK = ( qw( $foo ) ); our @EXPORT = qw(); our $VERSION = '0.01'; our $foo=1; 1; --usefoo.pl use strict; use warnings; use Foo qw($foo); print foo is $foo\n; $ perl usefoo.pl foo is 1 This is according to my instinct - and practice: I have been using this idiom, under strict, for the longest time and the interpreter has never raised an eyebrow about it. BTW, this also works with @IMPORT (not only with @IMPORT_OK). I cannot give you a doc pointer that explicitely says that it must be so (or why), though. Cheers, alf
Re: [OT?] Win32 permissions puzzler
Greetings.
Alessandro Forghieri wrote:
[...]
use Bar qw($foo);
if($foo) {
...
Global symbol $foo requires explicit package name at
use vars qw($foo);
use Bar qw($foo);
[...]
Not sure I am following you here. $foo is in the @EXPORT_OK list of module
Bar, which is, in turn,an Exporter. It is my understanding that this should
work (as it does after
the impersonated user has been given Admin powers).
Cheers,
alf
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
RE: perl's system() w/ apache under win2k
Greetings.
-Original Message-
[...]
Apparently permissions on winNT is something
unexpected and new for those who are used to older win32 systems.
Moreover, error_log usually tells what the exact problem is when the
code is written properly to report errors (e.g., checking the return
status of system()). My guess is that this should work on winNT too.
I am a little late on this one (vacations) however, it may be of general
[win32] interest highlighting the fact that the allow service to interact
with desktop thingy is just the start
of a more general can of worms that Win{Nt,2K} permissions and general
system interaction open up.
(None of these is mp specific, so sue me :-) )
For documentation purposes I am listing my most popular pet peeves below:
i) allow service to interact with desktop
Not only an issue with GUI-enbled apps, but also with apps that like to use
popups (say, through
MsgBox) and hang forever waiting fot somebody to press OK
ii) Access to networked disks/resources
NT services, by default, run as user LocalSystem which is pretty powerful on
the local machine and
totally powerless network-wide. This means that most accesses to network
resources *WILL* fail UNLESS the service is being told to impersonate a
specific user, whose password must be known and typed in the like-labeled
entry. If this course of action is chosen, then a special user should be
created for this purpose: this will prevent mysterious failures when a
sysadmin changes a password...But read on.
iii) DCOM configuration.
This can kick in for applications using out-of-process COM servers, most
often after the impersonation thing (see (ii)) has been set up. The fact
that DCOM is involved is a little puzzling, however WinNT and siblings
enforce DCOM security rules also across process boundaries.
Basically, one needs to be sure that the user (LocalSystem or whatever) that
the apache service impersonates is also in the access/launch/configure list
for the needed COM servers (this is tipically the default security list, but
an application is permitted to specify its own).
Sounds horrid enough? Wait 'til you've seen the interface of DCOMCNFG.exe -
the application that is used to configure DCOM security... (by the way, to
invoke this one, ypu need to type dcomcnfg in the Start-Run... dialog. It
is not on any menu/control panel applet I know of).
iv) Mounted drives
Drives that are permanently assigned a letter will not be available when
noone is logged on -
this cannot be solved by impersonation and I do not know wether a workaround
is available.
Finding these pitfalls is particularly tricky because they tend to disappear
if someone is logged on the machine, or if apache is run manually rather
than as a service etc. With regard to point (iii) it is interesting to note
that IIS works around it by creating a special user it runs under
(IUSR_fubar).
Cheers,
alf
RE: Trouble using mod_perl and IE5.x, IE6.x
Greetings. Now this is OT'ish but... print(titleTITRE DE LA PAGE\/title); Why are you escaping all your '/'s? There is no need to do it. Cheers, alf P.S: I strongly suspect that the sleep call and its position (what if you move it above the /body tag?) are to blame for the behavior you see (i.e. I'd bet you are triggering some timeout in IE). But that's only gut feeling.
RE: [OT] use http-equiv to refresh the page
Greetings. [...] [snip] CS:The W3C's stance on refresh is the same for the header as well as the CS:meta tag: they did not originally intend for it to be used to specify a CS:*different* URL as a rudimentary method of redirection. [...] i was bitten by this assumption recently. case in point: i needed to develop a way to display several images as a slideshow using plain html files. [..horror story clipped] But, in fact, redirects - either implicit or explicit - have many ways of biting the unwary (and curiously, or perhaps not, IE always a key role). Consider MS KB Article Q160013: If a CGI application returns a MIME Type that is unknown or not associated to Internet Explorer internally, Internet Explorer makes two POST requests to the server. What this means is that (for instance), sending a PDF file as the result of a POST request may cause the following sequence of events: 1) the file is downloaded 2) it is removed from the disk cache as the second POST request goes out 3) Acroread is launched and then says No such file. this bug is active on many, many versions of IE. It happens if you either send the file directly OR issue a redirect. The only workaround I could find was a meta-http-refresh. And then I found out that using '0' as a refresh time won't work on Mozilla (who tries to refressh the *current* page every 0 seconds and gets stuck in a loop- not nice). So what's a poor programmer to do, caught between standards and arguably buggy browsers? Cheers, alf P.S. Anybody knows of a better solution to Q160013, I'd like very much to hear about it...TIA.
RE: [OT] Apache::Session and Win32
Greetings. [...] Rob Bloodgood wrote: I tried Apache::Session::File, but after MUCH hair-pulling it seems that the Lock mechanism is COMPLETELY hosed (things are either never locked or never unlocked, or something...) AFAIK, Win32 has no flock. I once ran into the same problem - and my (superficial) analysis was that locks are not released for a reason that appears related to the multithreaded nature of the server...(for me, it was Apache). However, perlopentut says: Perl's most portable locking interface is via the flock function, whose simplicity is emulated on systems that don't directly support it, such as SysV or WindowsNT. The underlying semantics may affect how it all works, so you should learn how flock is implemented on your system's port of Perl. And perl's flock certainly appear to work between different processes on NT. FOr the record, I eventually resorted to null locking as well. Cheers, alf
RE: HTML::Template
Greetings. On Mon, 19 Aug 2002, Pierre Vaudrey wrote: with the following starnge error (The Title is displayed but not the vignette.gif file) [Mon Aug 19 07:22:24 2002] [error] Missing right curly or square bracket at /Library/WebServer/Documents/perl/vignette.gif line 1, at end of line syntax error at /Library/WebServer/Documents/perl/vignette.gif line 1, at EOF For some reason vingette.gif is being interpreted as a Perl script instead of an image. If (as I suppose) the /perl directory has PerlScript (or relatives) as handler, that is not strange at all... Moving vignette.gif elsewhere should make the problem disappear. Cheers, alf
RE: Mod_perl Application Development
Greetings. People often seem to get bent out of shape about putting a few Location directives in httpd.conf, I suspect that it may be due to the intimidating length that httpd.conf has reached in these times. I found that separating customizations in breakaway 'Include'd .conf files - and putting all my Include-s at the end of httpd.conf makes maintainence much easier (and upgrading apache relatively painless even under RPM's .rpmnew thing). Having Location directives [...] etc. without inventing your own config system. Warmly seconded. Cheers, alf
Weird: Perl/Perl [mp2]
Greetings. This happens on win32. If the following is inserted in httpd.conf: Perl /Perl I get, reasonbly enough: Syntax error on line 961 of D:/Apache2/conf/httpd.conf: Perl sections not yet implemented in modperl-2.0 Tough, but fair. But why should the following: IfDefine fubar Perl /Perl /IfDefine give me the totally unreasonable: Syntax error on line 960 of D:/think4/Apache2/conf/httpd.conf: Expected /Perl but saw /Perl Obviously minor, but gave me about 15 mins. of head scratching... Cheers, alf
perl-5.8-win32-bin.tar.gz missing files
Greetings.
I just installed the great perl-5.8-win32-bin.tar.gz package that Randy
Kobes mantains on uwinnipeg.
Two folders are missing from site/lib/Win32Api :
Registry/cRegistry.pc
File/cFile.pc
This is an installation bug of libwin32 - the files are generated but not
installed, so they must be manually moved to their intended destinations (I
was bit by the same thing and mailed the package maintainer about a month
ago). These are not binary files, so they can(?) be copied from
a same version installation of win32 (I used what I had on a 5.6.1-33 and
they appear to work fine).
Not quite in the bug category, I observed that the shipped version of
File::Basename::fileparse now croaks on calling fileparse(undef). This seems
a bit radical to me (given that fileparse('') just shuts up) - carp would be
fair, but croak seems pretty darn inhospitable to me...
Just my .02
Cheers,
alf
Mention LoadFile in the mp2 docs?
Greetings. From: http://perl.apache.org/docs/2.0/user/config/config.html#Enabling_mod_perl [...] Win32 users need to make sure that the path to the Perl binary (e.g., C:\Perl\bin) is in the PATH environment variable. [...] Is it not true that the directive LoadFile C:\foo\perl58.dll makes path modifications unnecessary? If so, it should perhaps be mentioned here. (With caveats, as situations where Registry scripts are handled by one - LoadFil-ed - perl version and CGI scriptse by another one - or not at all - would probably be confusing...). Cheers, alf
RE: List files from a share of a windows client
Greetings. on my machine: C:\ perl - e 42 -d Default die handler restored. Loading DB routines from perl5db.pl version 1.07 Editor support available. Enter h or `h h' for help, or `perldoc perldebug' for more help. main::(-e:1): 42 DB1 opendir(DIR,'//webteam/') || warn($!) No such file or directory at (eval 4)[D:/Perl/lib/perl5db.pl:1521] line 2. DB2 opendir(DIR,'//webteam/discoc/') || warn($!) DB3 x readdir(DIR) 0 'AUTOEXEC.BAT' 1 'baseclasses.log' 2 'bin' 3 'boot.ini' [...] //webteam is a machine name, //webteam/discoc a share name. So it should work (except if you want the share list of a machine, which you can get by using capabilities from the Win32:: namespace - or even from parsing `net view machine`...) Also if you are running apache as a service, be warned that the default impersonating user (LocalSystem) does not typically have access permissions to net share (this is especially true under NT Domain) - therefore you have to change the impersonating user of the service. (iven you have a working example this should not be your situation, however) Cheers, alf P.S: I have a feeling this may be OT, on the mod_perl list...
RE: while - modperl 2.0/Apache 2.0
Greetings. I have observed the same behavior (on win32). Scripts that are invoked from the same browser through the same URL appear to bind to the same perl thread and are therefore serialized. Changing the URL appears to bind the request to a different thread. (My observation regarded access from a different Location: Udei's experience shows that a URL change suffices). I have often wondered wether this is incidental or specified behaviour. Cheers, alf
RE: [win32] new perl/apache/mod_perl binary
Greetings [...] there's a better way - if anyone's familiar with this, could you drop me a mine, privately? Thanks. ^ Are you sure this is *really* what you want? : (Sorry I could not resist). Cheers, alf
RE: mod_perl 1.99 on Win2k with Apache2
Greetings. Nigel Peck wrote: Thanks for the help. When did I reply to you privately? This was just to reiterate for everybody to keep the threads on the list. Since many times those who respond to the questions, suffer afterwards because people decide that the person answering the question, is a free help desk that you can ask about anything, not talking about [...] Stas, as one that has been guilty of the same offence, let me point out that 99.9% of the time, seemingly private responses emerge from the list manager's policy of not munging the Reply-to: header - so the poor schmuck (me) hits reply and fires off a private reply to the poster. I know all about Reply-to: munging considered harmful and attending flame wars and I do not wish to delve into the relative pros and cons of the diveded camps (I'll just say that the lists I administer do the munging - period). What I wish to do is pointing out that - on non-munging lists - most standard clients require a conscious decision if they want to reply to the list, despite the fact that this would be the actual intention most of the times (so it makes for a poor interface). People stuck - like me - in Outlook-land have it even worse than most. Just my 0.02 cheers, alf
RE: Apache vulnerability: update of uwinnipeg win32 packages planned?
Greetings. Randy Kobes wrote: [...] There is still some demand for the all-inclusive apache/perl/mod_perl perl-win32-bin-x.x.exe binary packages we have, Uhm, yes I would be in that audience :) but I wasn't planning on making a new one of those until perl-5.8 is officially released. Any idea on when that may happen? In alternative, do you have any automated build environment for producing one of those? I would be willing to lend some CPU/man time to make that happen. Cheers, alf
Re: Thread bug in 5.8RC1 Win32
Greetings.
On Fri, Jun 14, 2002 at 12:44:50PM +0200, Alessandro Forghieri wrote:
Running NT4SP6, 5.8RC1 compiled debug.
The following session:
D:\Apache2perl -d -e 42
DB1 ;{use threads;my $var=1;threads-create(sub{$var++})-join();}
Crashes the intepreter, in perl.c:
[...]
Sorry to followup to myself, but I forgot to mention that the creash happens
*only* from within the debugger (perl -d). The mentioned code runs fine
otherwise - for instance, from within a file script.
Cheers,
alf
Thread bug in 5.8RC1 Win32
Greetings.
Running NT4SP6, 5.8RC1 compiled debug.
The following session:
D:\Apache2perl -d -e 42
Loading DB routines from perl5db.pl version 1.19
Editor support available.
Enter h or `h h' for help, or `perldoc perldebug' for more help.
main::(-e:1): 42
DB1 ;{use threads;my $var=1;threads-create(sub{$var++})-join();}
Crashes the intepreter, in perl.c:
/* Destroy the main CV and syntax tree */
if (PL_main_root) {
PL_curpad = AvARRAY(PL_comppad); =BLAM!
op_free(PL_main_root);
PL_main_root = Nullop;
}
Stack trace:
perl_destruct(interpreter * 0x01cf138c) line 445 + 9 bytes
Perl_ithread_destruct(interpreter * 0x015d6d7c, ithread_s * 0x01e9c6cc,
const char * 0x1000650c `string') line 130 + 12 bytes
ithread_mg_free(interpreter * 0x015d6d7c, sv * 0x01ce6098, magic *
0x02029e7c) line 200 + 18 bytes
Perl_sv_unmagic(interpreter * 0x015d6d7c, sv * 0x01ce6098, int 110) line
4687 + 18 bytes
Perl_ithread_join(interpreter * 0x015d6d7c, sv * 0x01ce6080) line 519 + 19
bytes
XS_threads_join(interpreter * 0x015d6d7c, cv * 0x01ce5f90) line 592 + 13
bytes
Perl_pp_entersub(interpreter * 0x015d6d7c) line 2758 + 16 bytes
Perl_runops_debug(interpreter * 0x015d6d7c) line 1398 + 13 bytes
S_run_body(interpreter * 0x015d6d7c, long 1) line 1670 + 13 bytes
perl_run(interpreter * 0x015d6d7c) line 1594 + 13 bytes
RunPerl(int 4, char * * 0x015e0210, char * * 0x015e0c70) line 202 + 12 bytes
main(int 4, char * * 0x015e0210, char * * 0x015e0c70) line 18 + 18 bytes
PERL! mainCRTStartup + 227 bytes
KERNEL32! 77f1b9ea()
Output of perl -V:
Summary of my perl5 (revision 5 version 8 subversion 0) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='cl', ccflags ='-nologo -Gf -W3 -Od -MD -Zi -DDEBUGGING -DWIN32
-D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT
-DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX',
optimize='-Od -MD -Zi -DDEBUGGING',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=4
alignbytes=8, prototype=define
Linker and Libraries:
ld='link', ldflags ='-nologo -nodefaultlib -debug
-libpath:D:\perl58\lib\CORE -machine:x86'
libpth=MSVCDir=C:\PROGRA~1\MICROS~4\VC98\lib
libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
msvcrt.lib
perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib
uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib
msvcrt.lib
libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
Dynamic Linking:
dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug
-libpath:D:\perl58\lib\CORE -machine:x86'
Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS
PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS
Built under MSWin32
Compiled at Jun 4 2002 09:08:01
INC:
D:/perl58/lib
D:/perl58/site/lib
.
Failure on modules and core tests for 5.8.0RC1
[ Recipients of this message are either subscribers to the modperl or
perlporters lists,
or listed as authors of theinvolved modules]
-Original Message-
From: [mailto:[EMAIL PROTECTED]]
Sent: Monday, June 03, 2002 9:38 PM
To: Alessandro Forghieri
Cc: [EMAIL PROTECTED]
Subject: Re: [2.x] test fails on win32 version 1.99_02
On Monday, 2002-06-03 at 18:32:54 +0200, Alessandro Forghieri wrote:
reetings.
:-)
I have been trying 5.8RC1 and I tried to compile/install
several modules
that I have
on 5.6.1 - CPAN, not PPM.
At least the following do not build and/or test right (not
exhaustive, as I
got tired after a while):
Posted in the hope it may help somebody...
[EMAIL PROTECTED] Wrote:
Can you please send a detailed report to the perl5porters list?
[EMAIL PROTECTED]
and the module authors? Please include the version numbers
and all error messages.
And so it goes... I am changing the subject, to make it more descriptive, as
this does not
really relate to modperl.
Machine is wintel NTSP6, VC++6 SP3.
1) Besides failures on various modules, I also witnessed (today) a SEGFAULT
on the tests while building a debug version (curiously, the stack trace ends
up in msvcrt - I would've expected msvcrtd).
The crash happens during:
../lib/Tie/File/t/12_longfetch_rs..
It appears to wedge in Perl_NEWFOROP:
#ifdef PL_OP_SLAB_ALLOC
{
LOOP *tmp;
NewOp(1234,tmp,1,LOOP);
Copy(loop,tmp,1,LOOP);//bm!
FreeOp(loop);
loop = tmp;
}
#else
the loop structure has a few fishy fields: loop-op_nextop and
loop-op_lastop both show up as expression that Cannot be evaluated by the
debugger (but maybe that's normal). As far as I remember, this did not
happen on a previous release build.
All other tests complete sucessfully.
2) and now on to the modules failures. I trid to reapply my 5.6.1 AS630
bundle and I had several failures. I tracked three of them more closely. Two
(Tk and Archive::Tar) are described below in a message I posted to perlmonks
yesterday. The third - MLDBM is described in what follows.
MLDBM-2.000 fails the first test of each suite. I debugged the first failure
(dumper.t) and
it fails a comparison on two would-be equal structures:
DB3 p $first
$a = [
1,
{
c = [
\'c'
],
a = $a,
b = $a-[1]
},
$a-[1]{c}
];
$b = {
c = [
\'c'
],
a = [
1,
$b,
$b-{c}
],
b = $b
};
$c = [
\'c'
];
DB4 p $second
$a = [
1,
{
a = $a,
b = $a-[1],
c = [
\'c'
]
},
$a-[1]{c}
];
$b = {
a = [
1,
$b,
[
\'c'
]
],
b = $b,
c = $b-{a}[2]
};
$c = [
\'c'
];
So this is pretty serious - given the above interpreter error in a 'tie'
test, some relation among the two can be inferred.
I also had uninvestigated failures in the following modules - all at their
latest CPAN versions:
o) Devel::TraceLoad 0.08 # Test Failure
t\allFAILED test 1
Failed 1/5 tests, 80.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\all.t51 20.00% 1
Failed 1/1 test scripts, 0.00% okay. 1/5 subtests failed, 80.00% okay.
o) Module::Info 0.12# Several test errors
Test returned status 16 (wstat 4096, 0x1000) DIED. FAILED tests 10-15,
40-47, 50-51
Failed 16/51 tests, 68.63% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\Module-Info.t 16 409651 16 31.37% 10-15 40-47 50-51
Failed 1/1 test scripts, 0.00% okay. 16/51 subtests failed, 68.63% okay.
o) Win32::API 0.20 #C diagnostic
API.c
API.xs(155) : error C2065: 'na' : undeclared identifier
API.xs(237) : warning C4244: '=' : conversion from 'double ' to 'float ',
possib
le loss of data
o) libxml-perl 0.07 # Fails test
D:\perl58\bin\perl.exe -MExtUtils::Command::MM -e
test_harness(0, '
blib\lib', 'blib\arch') t\amsterdam.t t\canon_xml_writer.t t\schema.t
t\stream.
t t\subs.t t\xp_sax.t
t\amsterdam...ok
t\canon_xml_writerok
t\schema..ok
t\stream..FAILED test 11
Failed 1/11 tests, 90.91% okay
t\subsok
t\xp_sax..ok
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\stream.t111 9.09% 11
Failed 1/6 test scripts, 83.33% okay. 1/45 subtests failed, 97.78% okay.
o)XML-RSS 0.97
is uncorrectly
modperl2 crashes under load (Win32)
Greetings.
I am hitting a complex Registry application with a number of almost
simultaneous, long running requests
(WinNT SP6 - VC++6 SP3 - perl5.8.0 RC1 - latest dev snapshot for modperl -
httpd-2.0_20020530041218.tar.gz for apache - everything built debug - a few
date.t tests fail on nmake test).
The crash happens in perllib.c at:
EXTERN_C PerlInterpreter *
perl_clone_host(PerlInterpreter* proto_perl, UV flags) {
dTHX;
CPerlHost *h;
h = new CPerlHost(*(CPerlHost*)PL_sys_intern.internal_host); //==
BLAAAMM!
proto_perl = perl_clone_using(proto_perl, flags,
h-m_pHostperlMem,
h-m_pHostperlMemShared,
h-m_pHostperlMemParse,
h-m_pHostperlEnv,
h-m_pHostperlStdIO,
h-m_pHostperlLIO,
h-m_pHostperlDir,
h-m_pHostperlSock,
h-m_pHostperlProc
);
[...]
Coming from modperl_interp_new.
I have not been able to reproduce this on simpler applications, so far (but
I will try).
I can also crash the same app under normal usage, however, but not
reproducibly so: a constant factor in the crashes (not in the one described
above, though) appears to be the appearance of bad header warnigns in
error.log: the crash follows shortly.
Note that the same app runs fine (no warnings whatsoever under modperl1).
I suspect that the threading code is to blame on all these crash counts: my
app has 3 frames, all hitting the same URL in rapid succession and this
appears to be brushing modperl the wrong way.
All of the above happens with the default intepreter pool settings: if I try
to
tune it, the application goes southwest immediately, only misteriously so -
it just spins, without warnings or anything.
Cheers,
alf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [2.x] test fails on win32 version 1.99_02
reetings. ok to try with perl 5.8.0 but i have many modules installed with ppm from http://theoryx5.uwinnipeg.ca/ppmpackages and those of activestate perl. I am able to install ppm package to a perl 5.8.0 i compile myself , without activestate ppm ? for instance modules that rely on a binary library like XML::LibXML or XML::Parser, and that don't install on win32 with usual perl makefile.pl etc I have been trying 5.8RC1 and I tried to compile/install several modules that I have on 5.6.1 - CPAN, not PPM. At least the following do not build and/or test right (not exhaustive, as I got tired after a while): TK # C error Archive::Tar # in getting file handles from zlib PPM # depends on the above MLDBM# de/serilized structures do not compare on tests Devel::TraceLoad # ?? Module::Info # Serious? Win32::API # Serious? C diagnostic libxml-perl # Fails test XML-RSS # contains XML::RSS.3 in man, unpack fails - builds otherwise. Other related modules build e.g.: XML:Parse builds/test Compress::Zlib builds/test (after some pain...) Posted in the hope it may help somebody... Cheers, alf
RE: mod_perl2: nmake test crashes apache
Greetings.
[...]
do you have a simple test case to reproduce the problem?
No, I do not. I hope I will be able get/build/test the latest CVS this week,
and perhaps I'll be able to work on making the problem
reproducible/debuggable which may well mean
I'll have to build a debugperl.
Some facts of the threads allocation are making me curious though
(euphemistic to say I don't really understand them). I am running a test
with a counter:
[...]
foreach my $count (0..20) {
$r-puts(lib$count/b/li\n);
sleep(1);
}
[...]
which I alias to two handlers (say /count1/ and /count2/).
If I then call it from the same browser in three separate frames like this:
| Frame 1 | Frame 2 | Frame 3
| htpp://localhost/count1/ | htpp://localhost/count2/ |
htpp://localhost/count1/
The execution order turns out to be: 1+2 and *then* 3. It looks like a
thread is allocated to this (client,handler) pair, so Frame 1 and 3 are
running in the same thread, separate from the thread that's running 2.
Is this reading correct, and is this behavior amenable to configuration?
(And is this a modperl question or an Apache question?)
iib) I then set out to build a debug version. That ain't
easy I finally
this has been fixed in cvs, MP_DEBUG=1 should do the right things now.
Great - I'll try it soon.
Cheers,
alf
RE: mod_perl2: nmake test crashes apache
Greetings. A few updates... i) modperl-2.0_20020514042137.tar.gz Now tests cleanly on: WinNT SP6/MSDEV 6 SP3/AS perl 5.6.1 b630/httpd-2.0_20020506161223.tar.gz ii) It does however crash on my testbed app (which runs as standard CGI, FastCGI and moperl1). The crash itself appears to happen when a number of nearly-simultaneous requests arrive to the server and is fatal to modperl (but the static-serving part of apache appears to survive) iia) On non-debug modperl in post-mortem examination within msdev I have been able to observe a seemingly incorrect r-pool thingy (casted to something else within table related something_palloc) triggering the segfault. iib) I then set out to build a debug version. That ain't easy I finally got it with semiautomatic Makefile mangling: perl Makefile.PL MP_INST_APACHE2=1 MP_AP_PREFIX=D:\Apache2 MP_GENERATE_XS=1 MP_DEBUG=1 MP_TRACE=1 find . -name Makefile -print | xargs perl -spi.bak -e s/-O1//g;s/-DNDEBUG//g;s/-release/-DEBUG -PDB:vc60.pdb/g; nmake [Explanation: the generated Makefiles have sequences of -O1 -Od -O1 *AND* the linkline misses the critical -DEBUG option. the PDB and -DNDEBUG things may not be needed.] After this the crash location moves (darn) and the debugger brings me in a location with nothing obviously wrong in sight. It is wedged on modperl_get_perl_module_config, called from XS_Apache_RequestRec_send_cgi_header etc. etc. Note: After switching to the debug version, I have started seeing apache errors - Your script did not blah blah - that were not there before, coupled to diagnostics from ModPerl::Registry complaining about not being able to call send_cgi_header on an undefined value. This may be significant. I will sendo more info when I have it... Cheers, alf
RE: mod_perl2: nmake test crashes apache
Greetings
Doug McEachern wrote:
[...]
avoiding use of PL_sv_no has cured all segfaults on win32.
the fixes have
been checked into cvs.
there are still a few tests that fail, but none that trigger
a segfault.
With the latest nodperl CVS snapshot the tally of the tests is much
improved.
There is a residual crash at dir_config.t (WinNT SP6 - MS Visual
Studio 6 SP3).
The debugger shows apache (debug version) going through the
ap_invoke_handler sequence before dumping me in the middle of
mod_perl's assembly. When it segfaults the stack (not cleared, this
time) shows a call into modperl the a trip into perl56.dll followed by
a call into request_util then modperl again (where it dies).
I re-ran the test suite without dir_config and all crashes go away,
though a few tests still fail.
At this point, I made a debug version of mod_perl (now possible - the
compiler warns about replacements of /O1 with /Od) and - lo and
behold! - the crash disappeared (darn). Also a few of the previously
failing tests now succeed
The tallies (with/without dir_config.t, and nmake test DEBUG) are
appendend below. Note that, in the first one, all tests coming after
dir_config fail ('coz apache is deeply unsettled, I think)
Cheers,
alf
Using the following snapshot:
modperl-2.0_20020513043636.tar.gz
httpd-2.0_20020506161223.tar.gz
apr-util_20020506162813.tar.gz
apr_20020506162759.tar.gz
-- output of nmake test --
D:\Apache2/bin/Apache.exe -d D:/builds/modperl-2.0/t -f D:/builds/mo
/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.37-dev (winnt MPM)
waiting for server to start: 00:00[Mon May 13 11:42:50 2002] [info] 1
modules loaded
[Mon May 13 11:42:50 2002] [info] 5 APR:: modules loaded
[Mon May 13 11:42:50 2002] [info] base server + 6 vhosts ready to run
[Mon May 13 11:42:50 2002] [info] 11 Apache:: modules loaded
[Mon May 13 11:42:50 2002] [info] 5 APR:: modules loaded
[Mon May 13 11:42:50 2002] [info] base server + 6 vhosts ready to run
END in modperl_extra.pl, pid=309
END in modperl_extra.pl, pid=309
END in modperl_extra.pl, pid=309
END in modperl_extra.pl, pid=309
END in modperl_extra.pl, pid=309
END in modperl_extra.pl, pid=309
END in modperl_extra.pl, pid=309
waiting for server to start: ok (waited 1 secs)
server localhost:8529 started
server localhost:8530 listening (TestDirective::perlmodule)
server localhost:8531 listening (TestDirective::perlrequire)
server localhost:8532 listening (TestProtocol::echo)
server localhost:8533 listening (TestProtocol::echo_filter)
server localhost:8534 listening (TestProtocol::eliza)
server localhost:8535 listening (TestFilter::input_msg)
apache\cgihandlerok
apache\compatok
apache\compat2...ok
apache\conftree..ok
apache\constants.ok
apache\post..ok
apache\read..ok
apache\scanhdrs..ok
apache\subprocessskipped: perl 5.7.3, cannot find module 'A
apache\write.ok
api\access...ok
api\aplogok
api\conn_rec.ok
api\lookup_uri...ok
api\lookup_uri2..ok
api\module...FAILED test 3
Failed 1/13 tests, 92.31% okay
api\r_subclass...ok
api\request_rec..ok
api\response.ok
api\rutilok
api\send_fd..ok
api\sendfile.ok
api\server_rec...ok
api\server_util..ok
api\uri..ok
apr\base64...ok
apr\constantsok
apr\date.ok
apr\netlib...ok
apr\perlio...skipped: iolayers is not available with this
Perl
apr\pool.ok
apr\string...ok
apr\tableok
apr\util.ok
apr\uuid.ok
directive\envFAILED tests 1-3
Failed 3/4 tests, 25.00% okay
directive\perlmodule.ok
directive\perlrequireok
directive\setupenv...ok
filter\api...ok
filter\buckets...ok
filter\input_bodyok
filter\input_msg.ok
filter\lcok
filter\reverse...ok
hooks\access.ok
hooks\authen.ok
hooks\authz..ok
hooks\fixup..ok
hooks\headerparser...ok
hooks\init...ok
hooks\trans..ok
modperl\dir_config...FAILED before any test output arrived
modperl\endavFAILED before any test output arrived
modperl\env..FAILED before any test output arrived
modperl\exit.FAILED before any test output arrived
modperl\getc.FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
modperl\pnotes...FAILED before any test output arrived
modperl\printFAILED before any test output arrived
modperl\printf...FAILED before any test output arrived
modperl\readline.FAILED tests 1-2
Failed 2/2 tests, 0.00% okay
modperl\sameinterp...must pass an interpreter id to work with at
odperl-2.0/Apache-Test/lib/Apache/TestRequest.pm line
mod_perl2: nmake test crashes apache
Greetings. Well now... There is a residual crash at dir_config.t (WinNT SP6 - MS Visual Studio 6 SP3). all tests pass for me with both 5.6.1 and bleedperl, httpd-2.0 from cvs on xp with msdev 6.0. i also tried 5.6.1 with no debug symbols, still all pass. would help to know which test causes the crash. you could try [...] This is embarassing. I rebuilt a no-debug modperl, re-ran the tests and dir_config.t passed with flying colors. I am really sure that it was failing this morning *EXCEPT* I did not ran nmake install before nmake test then. I think apache may be (sometimes?) picking up whatever mod_perl.so is under SERVER_ROOT/modules during the test run. Either that or I am getting senile-a possibility in itself. So, disregard my previous message, my failed line is now: Failed Test Stat Wstat Total Fail Failed List of Failed --- api\module.t 131 7.69% 3 3 tests skipped. And all is quiet. Cheers, alf P.S: I do have crashes in a real world app, buti I'll talk about them when I can characterize them - which I'm unable to do right now.
RE: mod_perl2: nmake test crashes apache
Greetings. [...] Apache builds and installs fine, mod_perl2 builds fine but running `nmake test` crashes the instance of apache2 created by the TEST script. [...] I have exactly the same behavior with May 6 snapshots (Visual Studio 6SP3, WinNT SP6) - quoting myself from a different thread: [RE: mod_perl failing on win32 (CVS snapshots)] [...] Yup. My 'nmake test' now segfaults at conftree.t, with an access violation somewhere in perl56.dll By running restricted test suites, I found out that the culprit appears to hide somewhere in compat2.t, i.e the sequence: perl -Mblib t\test t/apache/compat2.t t/apache/conftree.t wedges, whereas: perl -Mblib t\test t/apache/cgihandler.t t/apache/compat.t t/apache/conftree.t perl -Mblib t\test t/apache/cgihandler.t t/apache/conftree.t perl -Mblib t\test t/apache/compat.t t/apache/conftree.t are clean. (But note that for instance: perl -Mblib t\test t/apache/compat2.t t/apache/post.t also works. Combinatorial explosion, anyone?) [...] My test output is exactly the same as yours down to the memory addresses in the segfault dialog box. From hints in the above mentioned thread, looks like people running XP are experiencing fewer or different problems in the test suite. Cheers, alf
RE: mod_perl2: nmake test crashes apache
Greetings, [...] Hi about combinatorial I think not only compat2 is involved here in test suites I have ran [...] Wow. this is great detective work you have done Pascal. I have tried to go deeper and actually debug the thing. However, while I can get a debug version of apache I am stumped on a few counts: o) mod_perl does not compile with MP_DEBUG=1 (complains about an undefined _MP_debug_level) - and I doubt it is doing THE RIGHT THING anyways, because it adds a truely gcc-ish '-g' flag to the command line... o) mod_perl does not build against 5.007003 bleadperl (I wanted to test whether bleadperl had the same problem) o) the crash erases the call stack so all I can do is staring at mov edi,dword ptr [esi] Not very useful. And for the Curioser and curioser! department: I happened to run the test suite with a shell anvironment containing DEBUG=0 and TRACE=0 (ask not why...). Under these circumstances the test suite spins endlessly on conftree.t (rather than crashing). Folklore, perhaps, and hardly an improvement, but I am wondering who is checking those two variables? If I remove them from my environment, I get my old friend the crash back. Cheers, alf
mod_perl failing on win32 (CVS snapshots)
Greetings. Compiling and running the snapshots for BOTH apache and modperl (May 6th snapshots) on windowsNT sp6, I observe the following: i) the tests punt on conftree.t (it goes on forever) ii) installing and testing in a registry situation the request succeeds on the first invocation, but hangs on subsequent requests (either browser or CLI). The static server runs unabashed in the meantime. iii) Running conftree.t in isolation succeeds, so it is very likely that i) is a manifestation of (ii): conftree.t hangs because it is the second invocation into modperl. This experience validates an earlier thread of a poster having the same problem. BTW I see exactly the same when using th gold 2.0.35 Cheers, alf P.S. Compiling the httpd snapshot on Win32 is a royal pain, with tons of includes amiss: os.h, mod_core.h, mod_dav.h
Several problems for mod_perl2 in compatibility mode (Win32)
Greetings.
This is relative to several problems on Win32/NTSP6/AP build 630.
Short executive report: nothing seems to work :-)
-8-- Start Bug Report 8--
1. Problem Description:
I have tried these with both the released mod_perl *AND* the latest CVS
snapshot (no difference in either). The report was generated with the
snapshot, but symptoms
are identical for the released version.
While building:
if MP_DEBUG is set to 1:
Complaints of
Filter.obj : error LNK2001: unresolved external symbol
_MP_debug_level
..\..\..\blib\arch/Apache2\auto\Apache\Filter\Filter.dll : \
fatal error LNK1120: 1 unresolved externals
If MP_DEBUG is defined on Win32.
While Testing:
D:\Perl\bin\perl.exe -Iblib\arch/Apache2 -Iblib\lib/Apache2
t/TEST -clean
D:\Perl\bin\perl.exe -Iblib\arch/Apache2 -Iblib\lib/Apache2
t/TEST
D:\Apache2/bin/Apache.exe -d D:/builds/modperl-2.0/t \
-f D:/builds/modperl-2.0/t/conf/httpd.conf -DAPACHE2
-DPERL_USEITHREADS
using Apache/2.0.35 (winnt MPM)
waiting for server to start: ok (waited 1 secs)
server localhost:8529 started
server localhost:8530 listening (TestDirective::perlmodule)
server localhost:8531 listening (TestDirective::perlrequire)
server localhost:8532 listening (TestProtocol::echo)
server localhost:8533 listening (TestProtocol::echo_filter)
server localhost:8534 listening (TestProtocol::eliza)
server localhost:8535 listening (TestFilter::input_msg)
*** : cannot build c-modules without apxs
the server is down, giving up after 61 secs
!!! : failed to start server! (please examine D:t\logs\error_log)
NMAKE : fatal error U1077: 'D:\Perl\bin\perl.exe' : return code
'0x1'
Stop.
(apache keeps running afterwards)
Trying to actually use mod_perl in compatibility mode nothing appears to
work
(see detailed configuration below).
I tested scripts/application that run fine under Apache 1, mod_perl 1.26,
Apache::Registry
or straight CGI.
Scripts using CGI.pm return either:
o) an empty body (Apache::Registry)
o) a perl error - [Fri Apr 12 14:05:33 2002] [error] PerlRun: `Can't call
method args on an undefined
value at D:/Perl/lib/CGI.pm line 433.' (Apache::PerlRun)
The offending line contains a reference to Apache-request-args.
o) a stack overflow that crashes apache (complex app, under either registry
or perlrun)
(but since I cannot compile a debug version - see above - I can only see
what appears
to be a deep recursion somewhere in mod_perl.)
Not using CGI I can only get an empty body viz.:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
HTMLHEAD
META http-equiv=Content-Type content=text/html;
charset=iso-8859-1/HEAD
BODYXMP/XMP/BODY/HTML
This happens on elementary, Hello world type of scripts under either
PerRun
or Registry.
Configuration:
PerlModule Apache2
PerlModule Apache::compat
PerlRequire conf/startup.pl
Location /webteam/perl/bin/
Options +ExecCGI
SetHandler modperl
PerlResponseHandler Apache::Registry
PerlOptions +ParseHeaders
PerlOptions +SetupEnv
allow from all
/Location
startup.pl:
$ENV{MOD_PERL} or die not running under mod_perl!;
use Apache2 ();
use Apache::compat ();
use Apache::Registry ();
use Apache::PerlRun ();
use Carp ();
use CGI ();
CGI-compile(':all');
use CGI::Carp;
1;
2. Used Components and their Configuration:
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX= D:\Apache2
MP_DEBUG=
MP_GENERATE_XS = 1
MP_INST_APACHE2 = 1
MP_LIBNAME = mod_perl
MP_USE_DSO = 1
*** D:\Apache2/bin/Apache.exe -V
Server version: Apache/2.0.35
Server built: Apr 12 2002 09:31:06
Server's Module Magic Number: 20020329:0
Architecture: 32-bit
Server compiled with
-D APACHE_MPM_DIR=server/mpm/winnt
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT=/apache
-D SUEXEC_BIN=/apache/bin/suexec
-D DEFAULT_ERRORLOG=logs/error.log
-D SERVER_CONFIG_FILE=conf/httpd.conf
*** D:\Perl\bin\perl.exe -V
Summary of my perl5 (revision 5 version 6 subversion 1) configuration:
Platform:
osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread
uname=''
config_args='undef'
hint=recommended, useposix=true, d_sigaction=undef
usethreads=undef use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=undef d_sfio=undef uselargefiles=undef usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
Compiler:
cc='cl', ccflags ='-nologo -O1 -MD -DNDEBUG -DWIN32 -D_CONSOLE
-DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
-DPERL_MSVCRT_READFIX',
optimize='-O1 -MD -DNDEBUG',
cppflags='-DWIN32'
ccversion='', gccversion='', gccosandvers=''
Problems with 1.99_01 build when ap_prefix has blanks (Win32)
Greetings. I found that building with MP_AP_PREFIX=D:\Program Files\Apache2 is problematic. The build process chokes first in TestConfigParse: D:\Program Files\Apache2/bin/Apache.exe -l failed: Bad file descriptor at Apache-Test/lib/Apache/TestConfig.pm line 777, DATA chunk 1. If this is fixed by replacing my $cmd = $httpd -v; with my $cmd = \$httpd\ -v; in a few locations in TestConfigParse, the generation of the Makefile unravels after a little while with diagnostics like: Note (probably harmless): No library found for 'D:/Program' Note (probably harmless): No library found for 'Files/Apache2/lib/libapr.lib' I did not investigate this any further, as I choose to install under D:\Apache2 instead. Cheers, alf
Re: OT: Converting a ASP request to CGI?
Greetings.
Thanks to all the respondednts - as it looks my original message was too
terse, I'll try to clarify a bit.
I have an app that already works on Apache CGI.pm, Apache::Registry and
FastCGI.
It also works under PWS/IIS as CGI - and I'll be testing it under AS's
perlex shortly.
At present, the first thing it does is
use strict;
use CGI;
sub main {
my $q=new CGI;
#...
}
main();
1;
It then goes on to its errand, using $q, $q-param, $q-print to its heart
content.
I would like to plug it into IIS's ASP engine, ideally touching nary a line
of code, something along the lines of:
% @LANGUAGE = PerlScript
use CGI:FromAsp; #our valiant package.
my $q=CGI::FromAsp-new($Request);
#
# $q now looks and feels like a CGI.
# also print (or $query-print) does the RIGHT THING, and %ENV is what
# we'd expect it to be.
#
if ($q-isa('CGI')) { #it is..
$q-print($q-header(-type='text/html');
frobnicate($q);
$q-print($q-end_html());
} else {
print(h1CGI:FromAsp sucks like a tornado/h1\n);
}
%
Because my current knowledge of ASP is pretty basic, I do not know if it's
even possible... though it
sure looks like it should be.
Cheers,
alf
OT: Converting a ASP request to CGI?
Greetings. I realize this is an Off-Topic with serious flamage potential, so I'll keep it very short. Is anybody aware of any module capable of doing for the ASP environment what Apache::Registry does for mod_perl? (i.e. making an asp request look and feel as if it were an old plain cgi-bin) Cheers, alf
Re: Apache - mod_perl - Windows
Greetings. You may be in need of AddModule mod_perl.c After the ClearModuleList somewhere around line 207 of httpd.conf as distributed. (What's ClearModuleList's used for anyway? I never really understood it - but then again, I never really read its documentation...) As for mod_perl on win32, I am using it and the speed up in the load times is quite impressive. It does have a few glitches, the major possibly being that script execution is single threaded. Look for the relevant discussion in the list's archive (and in a forthcoming documentation upgrade). One thing I noticed on Win2k (but I believe it is Apache releated: as I recall, I saw it in a cgi-bin situation) is that scripts printing abundantly to stderr (which apache redirects to errorr_log) have a tendency to hang. This is an incentive to have a clena compile, if you use warnings ... or to redirect stderr to some other file ;) Cheers, alf
RE: Documentation patch for mod_perl//win32
Greetings. Stas so if Alessandro or Randy volunteers (please say so), please Stas ask winXX Stas users to send you more winXX specific notes/scenarios and you (the Stas volunteer) will be the official maintainer of the doc and send me the Stas new doc and then the future patches. For 2.0 you will simply have a Stas commit access and be able to maintain these by yourself and go wild. Stas Does this sound good? Randy It does ... I'd be happy to volunteer, or co-volunteer if Randy Alessandro or anybody else wants, to do that for Win32. I sure can co-maintain such a document. The co part is a good idea for several reasons - the most cogent being that I am not a native speaker (I'm italian) and that I spend most of my time working behind a firewall, so I'm not ideally suited for CVS access. And on this note, whenever Stas feels the revision process for this patch is over, I'll send the definitive version... Cheers, alf
Re: Documentation patch for mod_perl//win32
Greetings. Randy That's great that you thought this out and put it together; Randy a few comments below appear below ... Thanks for playing editor - and I am accepting all of your suggestions, with the possible exception of what follows. Randy I got confused about which is the first and which is the Randy second category ... However, is this much detail needed? The reason this section got in there is that a previous version of the guide included a highly opinionated quote against multithreading on single processor machines, which totally failed to take into account applications with long running requests (except for saying that such apps should not exist). Hence the counter-example, which I have now somewhat shortened. If there is still a consensus on it being overkill, I can drop it altogether. The revised version is below. Cheers, alf snipsnip =for RCS $Id: modperl_multithread_NT.pod,v 1.2 2001/11/21 10:09:30 forghier Exp forghier $ =head1 OS caveats: multithreading on Windows NT =head2 The problem On Win32, mod_perl is effectively single threaded. What this means is that a single instance of the interpreter is created, and this is then protected by a server-wide lock that prevents more than one thread from using the interpreter at any one time. The fact that this will prevent parallel processing of requests, including static requests, can have serious implications for production servers that often must handle concurrent or long-running requests. This situation will change with Apache/mod_perl 2.0, which is based on a multi-process/multi-thread approach using a native Win32 threads implementation. See http://perl.apache.org/~dougm/modperl_2.0.html for details. At the time of writing, Apache-2.0 is in a beta stage of development. mod_perl-2.0 is being actively developed, including the Win32 port; if you would like a preview and/or would like to contribute to the development process, see the documents on obtaining mod_perl-2.0 by cvs, which can be obtained from mod_perl's home page (http://perl.apache.org) =head2 Does it really matter? How serious is this? For some people and application classes it may be a non-problem, assuming the static material issue is handled differently. Low traffic and single user development sites will likely be unaffected (though the lattest are likely to experience some surprises when moving to an environment where requests are no longer serialized and concurrency kicks in). If your application is CPU bound, and all requests take roughly the same time to complete, then having more processing thread than processors (CPUs) will actually slow things down, because of the context switching overhead. Note that, even in this case, the current state of mod_perl will bar owners of multiprocessor Win32 machines from gaining a load balancing advantage from their superior hardware. On the other hand, applications dealing with a large service times spread - say ranging from fractions of a second to a minute and above - stand to lose a great deal of responsiveness from being single threaded. The reason is that short requests that happen to be queueued after long ones will be delayed for the entire duration of the jobs that precede them in the queue; with multitasking they would get a chance to complete much earlier. =head2 Workarounds If you need multithreading on Win32, either because your application has long running requests, or because you can afford multiprocessor hardware, and assuming you cannot switch operating system, you may want to consider a few workarounds and/or alternatives - which do not require waiting for 2.0. You may be able to make Win32 multithreading a non-issue by tuning or rearranging your application and your architecture (useful tips on both counts can be found elsewhere in this document). You may be able to significantly reduce your worst-case timing problems or you may find that you can move the webserver to a more mod_perl friendly operating system by using a multi tier scheme. If your application needs the full power of the Apache modules (often the case for people running outside Apache::Registry) you may want to consider a multi_server load balancing setup which uses mod_rewrite (or a similar URL partitioning scheme) to spread requests on several web servers, listening on different ports. The mod_proxy dual server setup,discussed in the Strategy section, is also a possibility, although people who have tried it have reported problems with Win32 mod_proxy. If you code to Apache::Registry (writing CGI compliant code) and can characterize the time demanded by a request from its URL, you can use a rewrite based load balancing with a single server, by sending short requests to mod_perl while routing longer ones to the pure CGI environment - on the basis that startup, compilation and init times will matter less in this case. If none of the above works for you, then you will have to turn to some non mod_perl alternatives: this,
Documentation patch for mod_perl//win32
Greetings. This documentationpatchaddressesthe single thread snafu on Win32. Comments, corrections and additions (even subtractions) welcome. (Also on the hot topic of the day: where in the doc does this fit?) Cheers, alf modperl_multithread_NT.pod Description: Binary data
Fastcgi on win [Was: Re: Documentation patch for mod_perl?]
Greetings.
[following Stas' suggestion I have subscribed to the list and
posted the patch there, so I am crossposting]
Do you know if FastCGI is multi-threaded or multi-process on
Windows?
Multi process. Each process speaks tomod_fastcgi over a
named pipe. As you mention, this (being multithreaded) avoids the problem
to which mod_perl succumbs.
[...]
Also, which FastCGI implementation do you recommend for
Windows?
I am in the process of testing mod_fastcgi, and that being
the only one I have seen so far, I should probably reccomend it...
;) It appears to be the only apache implementation by the
way. Also www.fastcgi.com
says that implementations for IIS and Iplanet were withdrawn by the firm that
was producing them.
Setting up is a bit of a pain (though recompiling perl with SFIO
is no longer required) Recompilationsmaybe required forapache,
mod_fastcgi,FCGI.pm. Also the Apache configuration can be a little
delicate.
After setup is taken care of, however, all it took to convert
the application was changing:
use CGI;
my $q=new CGI;
to
use FCGI;
use CGI::Fast;
my $q;
while($q=new CGI::Fast) {
}
So it wasn't bad, though I have to say that the app already
clears mod_perl and straight CGI, so it is exceptionally clean (by my
standards, at least).
I did run some tests - which basically check activation times, I
am working on getting more significant number on concurrency etc. Some patterns
do already emerge though:
Testing from a Linux box with:
ab -c30 -n 60 (30 concurrrent sessions, two requests each)
I get:
mod_perl (already compiled):
Concurrency Level: 30Time
taken for tests: 5.463 secondsComplete
requests: 60Failed
requests: 0Total
transferred: 292080 bytesHTML
transferred: 280620 bytesRequests per
second: 10.98Transfer
rate: 53.47 kb/s
received
Fast CGI (throttled at 4 concurrent servers already
running):
Concurrency Level: 30Time
taken for tests: 8.018 secondsComplete
requests: 60Failed
requests: 0Total
transferred: 292440 bytesHTML
transferred: 280980 bytesRequests per
second: 7.48Transfer
rate: 36.47 kb/s
received
Straight CGI gave me a server timed out with the same values. So
I lowered it to:
ab -c 10 -n 60
Concurrency Level: 10Time
taken for tests: 139.580 secondsComplete
requests: 60Failed
requests: 0Total
transferred: 292140 bytesHTML
transferred: 280680 bytesRequests per
second: 0.43Transfer
rate: 2.09 kb/s
received
So mod_perl has a slight speed edge over fastcgi (whichis
overthrottleda littlewith four servers). CGI is glacial as exepcted
- well, a little more actually, probablyaccounting for the catastrophic
event entailed bystarting a process on NT.
I plan to run some tests also on IIS with CGI and PerlEx and if
they're interesting I'll post them.
Cheers,
alf
Re: Documentation patch for mod_perl//win32
Greetings. [...] This documentation patch addresses the single thread snafu on Win32. Comments, corrections and additions (even subtractions) welcome. (Also on the hot topic of the day: where in the doc does this fit?) Nice, but please repost it inlined. Otherwise people won't be able to comment on your words. [...] hhh I see - attachment stripping. So here it comes - brace. -SNIP---SNIP---SNIP---(sigh, the good ole days) =head1 OS caveats: multithreading on Windows NT =head2 The problem mod_Perl's multithreading capability is severely limited on Win32 platforms (WinNT and Win2K). It is in fact limited to the point of non-existence: mod_perl on Win32 is single threaded. A single instance of the interpreter is created, and it is protected with a server-wide lock, that prevents more than one thread to be using the interpreter at any one time. It is actually a little worse than that, as not only does the interpreter lock prevents parallel processing of perl requests, it also prevents Bany request to proceed (yes, this means that static content requests will also be blocked). This rather unfortunate situation is supposed to change when Apache 2.0 and mod_perl 2.0 will be officially released: in the 2 series, with full multithreading support, apache will be managing an interpreter pool whose dimensions (among other parameter) will be tunable, as documented in http://perl.apache.org/~dougm/modperl_2.0.html The 2.0 release is still some time away unfortunately, which means that users of 1.3.x are stuck in single threaded world. =head2 Does it really matter? How serious is this? For some people and application classes it may be a non-problem, assuming the static material issue is handled differently. If your application is CPU bound, and all requests take roughly the same time to complete, then having more processing thread than processors (CPUs) will actually slow things down, because of the context switching overhead. Note that even in this case, the current state of mod_perl will bar owners of multiprocessor Win32 machines from gaining a load balancing advantage from their superior hardware. On the other hand, applications dealing with a large service times spread - say ranging from fractions of a second to a minute and above - stand to lose a great deal of responsiveness from being single threaded. The reason is that short requests that happen to be queued after long ones will be delayed for the entire duration of the jobs that precede them in the queue; with multitasking they would get a chance to complete much earlier. As a real life example, think a manufacturing application where, most of the time, users are navigating a Bill Of Material - a hierarchical structure. The requests generated by this usage pattern have a rather short service time, when moving from a component (node) of the BOM to one of its children or siblings. Now and then, however, a new Bill Of Material is requested, an operation that may require up to 25 seconds to complete. During this time lapse, all other requests are queued, nobody is able to use the system, and everybody complains about being stuck. By contrast, the very same application, Brunning against a fixed BOM, falls in the first category above, and may be perfectly happy in a single CPU mod_perl environment. =head2 Workarounds If you need multithreading on Win32, either because your problem falls in the second category or because you can afford multiprocessor hardware, and assuming you cannot switch operating system, there is not much you can do - other than waiting for 2.0, that is. The only mod_perl solution to this problem appears to be a multi_server load balancing setup which uses mod_rewrite (or a URL partitioning scheme) to spread requests on several web servers, listening on different ports. If you code to Apache::Registry (writing CGI compliant code) and can characterize the time demanded by a request from its URL, you can use a similar rewrite based load balancing with a single server, by sending short requests to mod_perl while routing longer ones to the pure CGI environment - on the basis that startup, compilation and init times will matter less in this case. If you cannot do any of the above, then you will have to turn to some non mod_perl alternative. For CGI compliant scripts, two possible (portable) alternatives which are supported in an Apache/perl environment are straight CGI and FastCGI. In theory a CGI application that runs under mod_perl should have very few or none problems to run under straight CGI (though its performance may be unacceptable). A FastCGI port should also be relatively painless. My personal test of this theory tends to corroborate it: starting from an Apache::Registry CGI script, I had no perl-related problems when moving it to a CGI environment and very few for FastCGI. (I Bdid have quite a few problems related to assumptions that the application made about its environment, but that is not
Re: Fastcgi on win [Was: Re: Documentation patch for mod_perl?]
Greetings. So mod_perl has a slight speed edge over fastcgi (which is overthrottled a little with four servers). Really? Maybe this is because multi-process handling isn't as fast on NT. Does it change much if you vary the number of servers? Well, I am getting a little wary of the numbers I get with ab, and on the significance of the -c[oncurrency] switch. In fact, by using different logins on the same client machine (rather than blasting the server from a single login), I get consistently lower request per second numbers than I previously posted (in the 7 rps for mod_perl, 5rps for fastcgi). Besides, as I am testing a single CPU load machine against a single CPU server machine, I am sort of measuring the ratio of the respective process/thread/whatever switching efficiency, whereas I would really need separate (or multiple CPU) clients. The gist of all this is that changing numbers of servers does not seem to matter much, but that happens at a juncture where nothing else does. For what it's worth though, mod_perl tends to be consistently a little faster. My goal is to give some kind of useful suggestion to people who need better performance on NT than mod_perl can currently give. That probably requires a definition of performance - not easy. If the goal is responsiveness, and response times are very variable, then anything (including CGI) would be more performant, given that a stuck mod_perl freezes the entire server. Other application domains, however, will probably warrant different metrics. From the vantage point where I am standing now, fastCGI does not look bad (but I really have to test it much more than this). For people that do not like the constraints of Apache::Registry, this solution may not be ideal at all, though... Cheers, alf
