Professional Web Applications Themes
  1. #1

    Default mod_perl, "use lib", and stuff ...

    Hi perlers,

    I'm developing a web based thing with mod_perl and apache. One of the
    things that has bugged me has been running 2 or 3 versions of the site
    (say dev and test), all using a common library "MyLib". The whole thing
    is under version control, with the layout looking like this (excuse
    abysmal attempt at line drawing):

    projectDir
    |
    |
    ----MyLib (contains "X.pm", "Y.pm"
    |
    |
    ---- site ---- cgi --- app.cgi

    Now app.cgi contains the following lines:

    use lib "../..";
    use MyLib::X;
    (blah)

    The site dir symlinks to /var/www/mysite, and at run time the intention
    (which seems to work) is that a given release sees it's own MyLib, the
    one in it's own projectDir.

    At least that's what I thought, until I started getting odd effects
    that indicated that maybe *some* of the processes were seeing a
    different "X.pm". Then I read the docs and gotthis:

    (snip)
    Even though @INC typically includes dot ("."), the current directory,
    this really isn't as useful as you'd think. For one thing, the dot
    entry comes at the end, not the start, so that modules installed in the
    current directory don't suddenly override system versions. You could
    say use lib "." if that's what you really want. More annoyingly, it's
    the current directory of the Perl process, not the directory that the
    script was installed into, which makes it completely unreliable. If you
    create a program plus some modules for that program to use, it will
    work while you're developing, but it won't work when you aren't running
    in the directory the files live in.
    (/snip)

    What the hell does THAT mean in teh context of mod_perl? What is the cd
    of the mod_pelr process? How is this thing working at all?

    And more to the point, what is a better way get the process to see the
    right modules, that I can set up from an installation script? i.e I
    want to export a tree from teh repository, and then run a script to set
    up the symlinks correctly - for more than version of the site.

    Thanks to anyone who can help unravel this knot. I can'ty be the first
    to tread this weary path ...

    Daniel

    danielmcbrearty@gmail.com Guest

  2. #2

    Default Re: mod_perl, "use lib", and stuff ...

    [email]danielmcbrearty@gmail.com[/email] wrote:
    > Hi perlers,
    >
    > I'm developing a web based thing with mod_perl and apache. One of the
    > things that has bugged me has been running 2 or 3 versions of the site
    > (say dev and test), all using a common library "MyLib". The whole thing
    > is under version control,
    Your problem is fundamental. Under mod_perl the Perl interpreter can
    persist from one request to the next. That's like the whole point. If
    a module has already been loaded during the processing of request 1 you
    don't have to pay the price of loading it again during the handling of
    request 2. The flip side of this is that if a module has already been
    loaded during the processing of request 1 then request 2 comes along
    and sets a different @INC you'll still be using whatever version was
    loaded first.

    In a development environment you can get over this by limiting each
    interpreter to handling a single request - but of course you loose most
    of the beniefit of mod_perl.

    Alternatively have a separate Apache instance per version.

    In mod_perl2 there's apparently a way of defining multiple pools of
    Perl servers (and I believe you can set @INC differently in each) and
    then assigning those pools to different virtual directories. That way
    you could get away with a single Apache. I suspect that if there were
    a significant number of versions about this could prove even less
    efficient than the one-request-per-interpreter solution.

    There may also be solutions using special Apache module like
    Apache::StatINC but IMNSHO any solution based on unloading Perl modules
    is likely to cause as many problems as it solves. (Note: I'm not saying
    Apache::StatINC would be any help at all, I'm saying a similar approach
    to that used in Apache::StatINC might be applicable).
    > (snip)
    > Even though @INC typically includes dot ("."), the current directory,
    > this really isn't as useful as you'd think. For one thing, the dot
    > entry comes at the end, not the start, so that modules installed in the
    > current directory don't suddenly override system versions. You could
    > say use lib "." if that's what you really want. More annoyingly, it's
    > the current directory of the Perl process, not the directory that the
    > script was installed into, which makes it completely unreliable. If you
    > create a program plus some modules for that program to use, it will
    > work while you're developing, but it won't work when you aren't running
    > in the directory the files live in.
    > (/snip)
    >
    > What the hell does THAT mean in teh context of mod_perl?
    You probably should never rely on relative paths in @INC when running
    mod_perl.

    Actually, you probably should never rely on relative paths in @INC when
    running perl. That is what the above stanza was trying to convey.

    nobull@mail.com Guest

  3. #3

    Default Re: mod_perl, "use lib", and stuff ...

    [email]nobull@mail.com[/email] wrote:
    > Alternatively have a separate Apache instance per version.
    This is (probably) the simplest thing to do.

    You can have one set of Apache executables and one set of web-site
    files, but multiple Apache configs (although most of that can be common too
    - just Include the majority of your config into a little file which has a:

    <Perl>
    use lib qw( /the/dir/I/want/for/this/one );
    </Perl>

    section in it), each setting different @INC in the configs. Run them on
    different ports to select which version you want.
    > In mod_perl2 there's apparently a way of defining multiple pools of
    > Perl servers (and I believe you can set @INC differently in each) and
    > then assigning those pools to different virtual directories.
    parent and clone options to a Perl* var IIRC.

    Also, I have a vague feeling that '.' isn't on @INC in mod_perl2 (may
    be wrong - enable perl-status to check...)




    --
    Just because I've written it doesn't mean that
    either you or I have to believe it.
    Big and Blue Guest

  4. #4

    Default Re: mod_perl, "use lib", and stuff ...

    Thanks. Good advice. Understanding the problem is all, as usual.

    I looked at various other fixes, like FindBin::Real and Perl_VINC
    modules, but none of them seemed to be quite what I wanted. In the end
    running two apache-perl instances was it - took a bit of figuring out,
    but looks a nice clean solution.

    danielmcbrearty@gmail.com Guest

Similar Threads

  1. Replies: 1
    Last Post: April 24th, 01:27 PM
  2. CFINPUT type="radio" w/ "value" requires "label"
    By Iceborer in forum Macromedia ColdFusion
    Replies: 2
    Last Post: February 21st, 06:16 PM
  3. Replies: 0
    Last Post: November 7th, 11:45 AM
  4. dr("field").toString returns "400.0000" instead of "400"
    By Dan C Douglas in forum ASP.NET General
    Replies: 5
    Last Post: July 22nd, 05:48 PM
  5. "Start" "Program" "Menu" list is empty
    By Pete in forum Windows XP/2000/ME
    Replies: 2
    Last Post: July 10th, 10:42 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139