On 18 Dec 2009, at 14:27, Ascii King wrote:
Could you please point out the specific section so I can GO BEAT IT
WITH A STICK. A STICK WITH RUSTY NAILS HAMMERED THROUGH IT. cough
I have done this, the documentation will be more accurate to what we
generally recommend in the next release.
You don't need FCGI::ProcManager under Windows. FCGI is enough, and it should
install OK. FCGI::ProcManager is only used when you pass --listen as it runs
FastCGI through TCP connections -- IIS uses named pipes so you don't want to
pass any TCP-related stuff. I've run the latest Catalyst fine
From: Tomas Doran bobtf...@bobtfish.net
On 16 Dec 2009, at 22:16, Octavian Râsnita wrote:
Using fastcgi under Windows is harder, and I don't even know if it can
run as an ExternalServer.
Yes, it totally can, however not on a local socket tcp-ip only.
I thought I need to install
Tomas Doran wrote:
Where, exactly?
Could you please point out the specific section so I can GO BEAT IT
WITH A STICK. A STICK WITH RUSTY NAILS HAMMERED THROUGH IT. cough
Thanks in advance.
t0m
Here:
http://search.cpan.org/dist/Catalyst-Manual/lib/Catalyst/Manual/Cookbook.pod#___top
I have an Apache 2.2.14 server with mod-perl 2.0.4 and Catalyst 5.80015
on a Windows XP machine.
My system runs fine from the built-in Catalyst web server. When I run
it through my Apache server, however it fails with the folowing error:
[info] NPC powered by Catalyst 5.80015
Free to wrong
Free to wrong pool is usually an issue with XS and threading.
Digest::SHA is an XS module. Which Perl are you using? And how is it
integrated into Apache?
I've generally found FastCGI to be safer on Windows, simply because it
doesn't require the tight integration of Perl into Apache under
Stuart Watt wrote:
Free to wrong pool is usually an issue with XS and threading.
Digest::SHA is an XS module. Which Perl are you using? And how is it
integrated into Apache?
I've generally found FastCGI to be safer on Windows, simply because it
doesn't require the tight integration of Perl
I did have FastCGI working. I switched because the Catalyst Cookbook
recommended mod_perl. I'll try that again.
Where, exactly?
Could you please point out the specific section so I can GO BEAT IT
WITH A STICK. A STICK WITH RUSTY NAILS HAMMERED THROUGH IT. cough
Thanks in advance.
t0m
Threading is possibly even worse on Windows. Any forking on Windows is
really Perl threading as Windows doesn't have fork() as its process model.
Are you using Randy Kobes' mod_perl for ActivePerl? I have not done that
configuration for a while, but I did get it working once. Your other
On 16 Dec 2009, at 21:00, Stuart Watt wrote:
FastCGI allows you to move Perl processes outside Apache, so they
are wholly independent of each other, and no longer require any
binary compatibility.
The downside is that you don't memory sharing, which you get with
prefork, especially on
Tomas Doran wrote:
Er, no - your fcgi process manager loads the app and calls fork() for
you, so you get memory sharing.
Sorry, you're right - we're using a very limited process manager and it
doesn't fork. We use some nasty nonthreadsafe legacy C code.
Since on Windows both types of fork are
Octavian Râsnita wrote:
If you use ActivePerl under Windows, mod_perl can be installed from
the TheoryX ppm repository and it doesn't require too much configuration.
Using fastcgi under Windows is harder, and I don't even know if it can
run as an ExternalServer.
For Apache possibly. The
On 16 Dec 2009, at 22:16, Octavian Râsnita wrote:
Using fastcgi under Windows is harder, and I don't even know if it
can run as an ExternalServer.
Yes, it totally can, however not on a local socket tcp-ip only.
But dynamic FCGI Catalyst works out the box with IIS if you want the
easiest
13 matches
Mail list logo