FAQ
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 pool 760e18 not 26fe70 at C:/Perl/lib/Digest/SHA.pm line
63 during global destruction.
[Wed Dec 16 12:22:34 2009] [crit] (OS 6)The handle is invalid. :
master_main: create child process failed. Exiting.


The Digest::SHA is used to handle the login, of course. I have used the
example from the tutorial. Any ideas why this is occurring? If I remove
the call from the Schema/Result/Account.pm, it will run.

__PACKAGE__->add_columns(
'password' => {
data_type => "TEXT",
size => undef,
encode_column => 1,
encode_class => 'Digest',
encode_args => {salt_length => 10},
encode_check_method => 'check_password',
},
};


I was going to switch to blowfish, but I keep getting a 'bad bcrypt
settings' error. I read that it is for Unix only though, so I guess I
should have expected that.

Search Discussions

  • Stuart Watt at Dec 16, 2009 at 7:42 pm
    "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 Windows.

    --S
    --
    Stuart Watt
    ARM Product Developer
    Information Balance


    Ascii King wrote:
    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 pool 760e18 not 26fe70 at C:/Perl/lib/Digest/SHA.pm line
    63 during global destruction.
    [Wed Dec 16 12:22:34 2009] [crit] (OS 6)The handle is invalid. :
    master_main: create child process failed. Exiting.


    The Digest::SHA is used to handle the login, of course. I have used
    the example from the tutorial. Any ideas why this is occurring? If I
    remove the call from the Schema/Result/Account.pm, it will run.

    __PACKAGE__->add_columns(
    'password' => {
    data_type => "TEXT",
    size => undef,
    encode_column => 1,
    encode_class => 'Digest',
    encode_args => {salt_length => 10},
    encode_check_method => 'check_password',
    },
    };


    I was going to switch to blowfish, but I keep getting a 'bad bcrypt
    settings' error. I read that it is for Unix only though, so I guess I
    should have expected that.

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

    --
    This message was scanned by ESVA and is believed to be clean.
    Click here to report this message as spam.
    http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=CF5252806D.4D760
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091216/bec400aa/attachment.htm
  • Ascii King at Dec 16, 2009 at 8:28 pm

    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 into Apache under Windows.

    --S
    --
    Stuart Watt
    ARM Product Developer
    Information Balance
    I have Perl v5.8.9 I suspected it was something to do with threads only
    because I couldn't figure out how threading or the pre-fork stuff was
    supposed to be set up on Windows. I thought I read though, that the
    threading issue didn't matter on Windows.


    I did have FastCGI working. I switched because the Catalyst Cookbook
    recommended mod_perl. I'll try that again.
  • Tomas Doran at Dec 16, 2009 at 8:40 pm

    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
  • Ascii King at Dec 18, 2009 at 2:27 pm

    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

    "mod_perl is the best solution for many applications, but we'll list
    some pros and cons so you can decide for yourself."


    I have apache and mod_perl working together. My error only shows up if I
    have Digest::SHA in use in the application. I'll try it with FastCGI,
    though.
  • Tomas Doran at May 22, 2010 at 10:16 am

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

    Cheers
    t0m
  • Stuart Watt at Dec 16, 2009 at 9:00 pm
    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
    option is to compile your own Apache+mod_perl -- a bit of a challenge
    but certainly possible, and quite likely to resolve the problem.

    The problems arise because mod_perl has to plug the whole of Perl into
    Apache. This requires Apache and Perl to be compiled in ways that are
    partly compatible. mod_perl has some flexibility in this, but I always
    found it pretty troublesome, and in any event, the Perl threads on
    Windows will be within Apache processes. 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 platforms that have a proper process fork().
    Unfortunately, Windows doesn't have that true fork(), so the memory
    sharing is only working because you are working in a single (Windows)
    process. Our Perl processes on Windows are not that big (they commonly
    start at VM sizes of 50-60Mb, and only get larger when we start the
    high-powered search systems we use). A decent server can easily
    accommodate 40 or so of these.

    Personally, on Windows, I'd stick with FastCGI. We've been using it for
    a year or more and it has survived some fairly large scale stress testing.

    --S
    --
    Stuart Watt
    ARM Product Developer
    Information Balance


    Ascii King wrote:
    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 into Apache under
    Windows.

    --S
    --
    Stuart Watt
    ARM Product Developer
    Information Balance
    I have Perl v5.8.9 I suspected it was something to do with threads
    only because I couldn't figure out how threading or the pre-fork stuff
    was supposed to be set up on Windows. I thought I read though, that
    the threading issue didn't matter on Windows.


    I did have FastCGI working. I switched because the Catalyst Cookbook
    recommended mod_perl. I'll try that again.

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

    --
    This message was scanned by ESVA and is believed to be clean.
    Click here to report this message as spam.
    http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id=0E7092806D.D7113
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091216/511752ce/attachment.htm
  • Tomas Doran at Dec 16, 2009 at 9:11 pm

    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 platforms that have a proper process fork().
    Er, no - your fcgi process manager loads the app and calls fork() for
    you, so you get memory sharing.

    In mod_perl, apache is driving, so it calls fork(), and then asks the
    perl interpreter to clone itself. This also tries to 'do the right
    thing', keeping preloaded code shared.

    IME, mod_perl tends to be _less_ efficient at this (as interpreter
    cloning is less trivial than simple fork), but you get (at least some
    of) the same shared memory / copy on write effect from both, even on
    win32 where fork() is emulated.

    Cheers
    t0m
  • Stuart Watt at Dec 16, 2009 at 9:33 pm

    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 emulated in Perl, whether in
    mod_perl or in the FCGI process manager, I guess the performance is
    almost equivalent. (Is this true? -- anybody benchmarked the two??)

    That just leaves the pain of setting up mod_perl. I used to do that, but
    I never really enjoyed it.

    --S

    Stuart Watt
    ARM Product Developer
    Information Balance

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091216/17bcbf2a/attachment.htm
  • Octavian Rasnita at Dec 16, 2009 at 10:16 pm
    From: "Stuart Watt" <swatt@infobal.com>
    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 emulated in Perl, whether in
    mod_perl or in the FCGI process manager, I guess the performance is
    almost equivalent. (Is this true? -- anybody benchmarked the two??)

    That just leaves the pain of setting up mod_perl. I used to do that, but
    I never really enjoyed it.

    --S

    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.

    Octavian
  • Stuart Watt at Dec 16, 2009 at 10:52 pm

    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 mod_perl "clone" for IIS (ActiveState's PerlEx)
    is virtually unsupported and has (had?) low-level bugs; because it is
    closed source there is almost nothing you do can about them.

    We were therefore effectively forced into using FastCGI, which has
    certainly proven portable, scalable, and with acceptable performance
    even under IIS. (IIS, need I say it, was not our choice). IIS FastCGI
    support is now pretty good because of the Zend/Microsoft collaboration,
    although PHP is the principal beneficiary.

    Don't get me wrong - I was a big fan of Apache and mod_perl on Windows,
    I was compiling it for mission-critical applications in 2001 -
    applications which were still in use and running stable on the same
    server 8 years later!!!

    All the best
    Stuart
    --
    Stuart Watt
    ARM Product Developer
    Information Balance
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20091216/06b94fb5/attachment.htm
  • Tomas Doran at Dec 16, 2009 at 11:14 pm

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

    Cheers
    t0m
  • Octavian Rasnita at Dec 25, 2009 at 1:46 pm
    From: "Tomas Doran" <bobtfish@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 FCGI::ProcManager in order to use fastcgi. I
    wasn't able to install this module under Windows, although I tried with both
    ActivePerl and Strawberry Perl.

    Octavian
  • Stuart Watt at Dec 27, 2009 at 7:52 pm
    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 under Windows IIS with *only* the --keeperr passed (IIS can be funny about standard error, although there are more options relating to this in the 1.5 update to the IIS FastCGI component). IIS does the process management for you and allows control through the settings in the fcgiext.ini file.

    All the best
    Stuart


    On 2009-12-25, at 8:46 AM, Octavian R?snita wrote:

    From: "Tomas Doran" <bobtfish@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 FCGI::ProcManager in order to use fastcgi. I wasn't able to install this module under Windows, although I tried with both ActivePerl and Strawberry Perl.

    Octavian


    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

    --
    This message was scanned by ESVA and is believed to be clean.
    Click here to report this message as spam. http://antispam.infobal.com/cgi-bin/learn-msg.cgi?id,57A2807C.22BB9
  • Tomas Doran at Dec 16, 2009 at 11:13 pm

    On 16 Dec 2009, at 21:33, Stuart Watt wrote:
    Since on Windows both types of fork are emulated in Perl, whether in
    mod_perl or in the FCGI process manager, I guess the performance is
    almost equivalent. (Is this true? -- anybody benchmarked the two??)
    No idea.

    Does it matter?

    Given your processes are persistent and serve many hits before being
    recycled, you're not going to be calling fork() often enough to care?

    Cheers
    t0m

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedDec 16, '09 at 7:12p
activeMay 22, '10 at 10:16a
posts15
users4
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase