Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Date: Tue, 21 Sep 2010 15:28:47 +0300
From: Tuomo Salo <Tuomo.Salo@cybercom.com>
To: Sharon Pattison <scp02230@gmail.com>
Cc: modperl@perl.apache.org
Subject: Re: Strange process behavior
Message-ID: <20100921122847.GK8516@cybercom.com>
References: <AANLkTikKRD4XcicEBHpOWeWzigJLC2xLaf8yDVC+Pz5c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <AANLkTikKRD4XcicEBHpOWeWzigJLC2xLaf8yDVC+Pz5c@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)

Are you getting "variable will not stay shared" messages in your error_log?

If you are, you might be using a lexical variable outside of the function
it was defined in. When this happens, you'll get a closure, which is a 
useful tool sometimes, but for us regular people it means that old data
will unexpectedly stay in the variables from one request to the other.

The fix is to make sure that every variable (that is not meant to be global)
is declared as "my" inside any sub where it is used.

http://modperlbook.org/html/22-2-1-Value-of-x-will-not-stay-shared-at-line-5.html

  -Tuomo

On Mon, Sep 20, 2010 at 11:52:50AM -0400, Sharon Pattison wrote:
> Hi,
> 
> 
> We are experiencing a strange problem on our web servers for our site, and
> are not sure if the problem is mod_perl related, but thought we would turn
> here for help in case someone else has experienced this issue.
> Unfortunately, we are not sure exactly when the problem started, so we can’t
> point to any particular change that might have prompted it.
> 
> 
> 
> We are using Apache 1.3.42 with mod_perl 1.31 and Perl 5.8.3 on Solaris 9.
> What is happening is that a particular Apache child process starts having an
> issue where the wrong content is being returned for a request.  The content
> returned is always from the correct script, but it has the wrong data.  For
> example, if we request a product detail page for a particular product, we
> might get a different product, or we might get a message that the product
> does not exist, when it does.
> 
> 
> 
> After adding a lot of logging to our logs, we discovered that the Apache
> request object will have the correct information, but the CGI object never
> seems to get the global values reset, so is always has the query_string of
> the request where things started to go wrong.  The process will continue to
> get and respond to requests, but the CGI object’s query_string never
> changes, so the user either gets no information or the wrong information.
> 
> 
> 
> For example, if we had a request for mysite.com/product?sku=12345, and the
> process that served this request starts to have the problem, then we see
> that for every request that process gets, logging $q->query_string gives us
> ‘sku=12345’.  It seems like the initialize_globals() CGI method is never
> being executed in the process cleanup.
> 
> 
> 
> There doesn’t seem to be any particular request that triggers this
> behavior.  We have checked the server load when we discover the issue is
> occurring and everything seems normal.  The problem process does not seem to
> be using any more memory or CPU than any of the other processes, and the
> number of processes is fine.
> 
> 
> 
> Has anyone experienced anything like this?  Any ideas how we can track down
> the problem?
> 
> 
> 
> Thank you in advance for any help you can give us.
> 
> 
> 
> Sharon