Hi, I think I sent my last reply just to Tuomo, so am sending again to the list......
Thanks for the suggestion. I checked our error logs and did not find that message anywhere. We added some logging to several of our scripts to log when $r->args and $q->query_string do not match. What we find for the bad process is that $r always has the correct data for the new request, but the value of $q->query_string never changes once the problem starts. Here's a shortened example of what we are logging: [Sat Sep 18 01:14:06 2010] [error] INFO LOGGER: Mismatched query strings: r = item_code=WW&item_no=293845&view=details, q = sku=828752&slide=2||PID: 2309 [Sat Sep 18 01:14:10 2010] [error] INFO LOGGER: Mismatched query strings: r = sp=102686, q = sku=828752&slide=2||PID: 2309 [Sat Sep 18 01:14:12 2010] [error] INFO LOGGER: Mismatched query strings: r = , q = sku=828752&slide=2||PID: 2309 [Sat Sep 18 01:14:20 2010] [error] INFO LOGGER: Mismatched query strings: r = N=1108281+5401+10006, q = sku=828752&slide=2||PID: 2309 [Sat Sep 18 01:18:53 2010] [error] INFO LOGGER: Mismatched query strings: r = item_no=312108, q = sku=828752&slide=2||PID: 2309 This will continue until the process with PID 2309 dies, and it happens with any script that is requested. We are doing some internal redirects as Perrin mentioned, but we are not redirecting every time we see this happen, so I can't say that redirects are causing the problem. At the same time this is happening, all other child processes are behaving normally. Sharon On Tue, Sep 21, 2010 at 8:28 AM, Tuomo Salo <tuomo.s...@cybercom.com> wrote: > 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 >
