Return-Path: Delivered-To: apmail-perl-modperl-archive@www.apache.org Received: (qmail 45368 invoked from network); 12 Feb 2008 02:40:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Feb 2008 02:40:20 -0000 Received: (qmail 98580 invoked by uid 500); 12 Feb 2008 02:40:09 -0000 Delivered-To: apmail-perl-modperl-archive@perl.apache.org Received: (qmail 98300 invoked by uid 500); 12 Feb 2008 02:40:08 -0000 Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list modperl@perl.apache.org Received: (qmail 98288 invoked by uid 99); 12 Feb 2008 02:40:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Feb 2008 18:40:07 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [210.193.32.133] (HELO mail.nexlabs.com) (210.193.32.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 Feb 2008 02:39:36 +0000 Received: (qmail 55988 invoked from network); 12 Feb 2008 02:40:29 -0000 Received: from 24.203-123-20.1500adsl.qala.com.sg (HELO ?192.168.1.173?) (jhfoo@nexlabs.com@203.123.20.24) by www.nexlabs.com with SMTP; 12 Feb 2008 02:40:29 -0000 Message-ID: <47B106D9.7080606@extracktor.com> Date: Tue, 12 Feb 2008 10:39:21 +0800 From: Foo JH User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dylan Tynan CC: modperl@perl.apache.org Subject: Re: @inc ithreads virtual server +parent References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org 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 >