@inc ithreads virtual server +parent

@inc ithreads virtual server +parent

am 11.02.2008 15:44:10 von Dylan Tynan

This is a multi-part message in MIME format.

------_=_NextPart_001_01C86CBC.8E640F3A
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I'm looking at the information in mod_perl 2 User's Guide (and online)
about using VirtualHost and +Parent, with an ithreads-enabled Perl, in
order to be able to modify @inc by virtualserver. On my system I
basically have that setup, and have tried it, and it seems to work fine
(I tried it with prefork, though that appears not to matter except for
the inefficiency of course).

=20

I'm wondering what would happen if I -didn't-have an ithreads-enabled
Perl, but still set up the httpd.conf with the virtual-host/+parent
stanzas? Will it fail on startup with an error about +parent being
unsupported or some other error? Or does it run fine but I end up with
a shared @inc across all virtual servers perhaps? .............. I have
a somewhat limited customer set and each customer will probably run a
test & production setup, with mostly the same code in each environment
(thus @inc conflicts). I'm wondering what, if anything, they might
see....

=20

I take it the only real way around the above situation is either to use
an ithreads-enabled Perl or to run separate apaches... is there some
other way?

=20

Thanks!

Dylan


------_=_NextPart_001_01C86CBC.8E640F3A
Content-Type: text/html;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40">


charset=3Dus-ascii">









I’m looking at the information in mod_perl 2 =
User’s
Guide (and online) about using VirtualHost and +Parent, with an
ithreads-enabled Perl, in order to be able to modify @inc by
virtualserver.   On my system I basically have that setup, and =
have
tried it, and it seems to work fine (I tried it with prefork, though =
that
appears not to matter except for the inefficiency of =
course).



 



I’m wondering what would happen if I =
–didn’t—have
an ithreads-enabled Perl, but still set up the httpd.conf with the
virtual-host/+parent stanzas?   Will it fail on startup with =
an error
about +parent being unsupported or some other error?  Or does it =
run fine
but I end up with a shared @inc across all virtual servers perhaps? =
………….. 
I have a somewhat limited customer set and each customer will probably =
run a
test & production setup, with mostly the same code in each =
environment (thus
@inc conflicts).   I’m wondering what, if anything, they =
might
see….



 



I take it the only real way around the above =
situation is
either to use an ithreads-enabled Perl or to run separate apaches… =
is
there some other way?



 



Thanks!



Dylan









------_=_NextPart_001_01C86CBC.8E640F3A--

Re: @inc ithreads virtual server +parent

am 11.02.2008 21:04:49 von Perrin Harkins

On Feb 11, 2008 9:44 AM, Dylan Tynan wrote:
> I'm wondering what would happen if I =96didn't=97have an ithreads-enabled=
Perl,
> but still set up the httpd.conf with the virtual-host/+parent stanzas?

Try it and see. I doubt anyone will know offhand.

> I take it the only real way around the above situation is either to use a=
n
> ithreads-enabled Perl or to run separate apaches=85 is there some other w=
ay?

You can make your module names unique so they don't conflict.

If you're not on Windows, there are good reasons to avoid ithreads
(performance hit, memory overhead), so I always go with the separate
apaches approach.

- Perrin

Re: @inc ithreads virtual server +parent

am 11.02.2008 21:43:55 von Chandrakumar Muthaiah

This is a multi-part message in MIME format.

--Boundary_(ID_uX2mmhx8BZKwT3ySEZ85VA)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT


Perrin Harkins wrote:
> On Feb 11, 2008 9:44 AM, Dylan Tynan wrote:
>
>> I'm wondering what would happen if I --didn't---have an ithreads-enabled Perl,
>> but still set up the httpd.conf with the virtual-host/+parent stanzas?
>>
>
> Try it and see. I doubt anyone will know offhand.
>
>
>> I take it the only real way around the above situation is either to use an
>> ithreads-enabled Perl or to run separate apaches... is there some other way?
>>
>
> You can make your module names unique so they don't conflict.
>
> If you're not on Windows, there are good reasons to avoid ithreads
> (performance hit, memory overhead), so I always go with the separate
> apaches approach.
>
> - Perrin
>

Perrin, I think you deserve lots of appreciations. Just want to let it out.

--Boundary_(ID_uX2mmhx8BZKwT3ySEZ85VA)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT









Perrin Harkins wrote:
cite="mid:66887a3d0802111204j4aa5fb0fs8d725cdb7aa326fc@mail. gmail.com"
type="cite">

On Feb 11, 2008 9:44 AM, Dylan Tynan  wrote:


I'm wondering what would happen if I –didn't—have an ithreads-enabled Perl,
but still set up the httpd.conf with the virtual-host/+parent stanzas?



Try it and see. I doubt anyone will know offhand.



I take it the only real way around the above situation is either to use an
ithreads-enabled Perl or to run separate apaches… is there some other way?



You can make your module names unique so they don't conflict.

If you're not on Windows, there are good reasons to avoid ithreads
(performance hit, memory overhead), so I always go with the separate
apaches approach.

- Perrin




Perrin, I think you deserve lots of appreciations. Just want to let it
out.




--Boundary_(ID_uX2mmhx8BZKwT3ySEZ85VA)--

Re: @inc ithreads virtual server +parent

am 12.02.2008 03:39:21 von Foo JH

Dylan,

Let's see: you have a client base who likes a staging-production
development scenario. There's a few ways you can play it out:

1. Different client, different code base
You use 2 machines: 1 for staging and the other for production. Set them
up exactly the same. Run your VirtualHost for each client. Since it's a
unique code base for each client, there is no fear of code
contanimation. Life is quite simple here.

2. Different client, same code base
You're probably setting up a product for PoC (hence the same code base),
with a slightly different config for each client.

a. Turning on +Parent should do the trick (with ithreads), but you need
to test it out a bit to make sure you got it right.

b. Since it's staging anyway, there's no need to spawn all the child
threads/ processes. In which case you can create multiple instances of
Apache for each client (perhaps even 1 for staging and another for
production) with a minimal thread/ process count to save memory/ cpu.
This method allows you to use either ithreads (which is only encouraged
for Win32 platform) or prefork (Linux).

Having said that, production servers should ideally be free of unstable
code. So putting staging stuff in the same box is not advised, unless
your clients are very forgiving. :)


Dylan Tynan wrote:
>
> I’m looking at the information in mod_perl 2 User’s Guide (and online)
> about using VirtualHost and +Parent, with an ithreads-enabled Perl, in
> order to be able to modify @inc by virtualserver. On my system I
> basically have that setup, and have tried it, and it seems to work
> fine (I tried it with prefork, though that appears not to matter
> except for the inefficiency of course).
>
> I’m wondering what would happen if I –didn’t—have an ithreads-enabled
> Perl, but still set up the httpd.conf with the virtual-host/+parent
> stanzas? Will it fail on startup with an error about +parent being
> unsupported or some other error? Or does it run fine but I end up with
> a shared @inc across all virtual servers perhaps? ………….. I have a
> somewhat limited customer set and each customer will probably run a
> test & production setup, with mostly the same code in each environment
> (thus @inc conflicts). I’m wondering what, if anything, they might see….
>
> I take it the only real way around the above situation is either to
> use an ithreads-enabled Perl or to run separate apaches… is there some
> other way?
>
> Thanks!
>
> Dylan
>