in reply to Re^6: apache/perl caching problem
in thread apache/perl caching problem
If you have stopped and restarted your apache server and are still receiving responses from old versions of your script, then the problem is not a simple case of mod_perl holding old versions in memory.
By "standard CGI script" I mean a script that is read from disk and executed once for each request. An implication (or perhaps I should say assumption of mine) is that a perl interpreter is started for each request. This is in distinction to a script running in the context of mod_perl, FastCGI or some other context which transforms or encapsulates it in a persistent process that handles several requests before terminating.
For "quick and dirty" logging (i.e. to be removed when debugging is done, as opposed to logging that is to become a permanent part of the scripts) I usually print to STDERR. Output to STDERR should show up in your sites error log. This allows you to see information that is not available in the access logs.
You could use CGI::Log or CGI::LogCarp.How you get information into the logs is less important than what information is recorded there.
You are correct that adding logging to new versions of your script will not change older versions. None the less, it would be good to add some logging. Your current versions will soon become old versions. You might produce a few versions that differ only in the version numbers they log, just to make some versions with enhanced logging into old versions.
The HTTP protocol is one of request and response. The browser sends a request and the server sends a response. While the requests and responses can be complex, the relationship between them is usually very simple: one request receives one response.
You have "bad" responses being received at the browser. The challenge is to determine where these "bad" responses are coming from and why they are being produced. The first step is to determine where they are coming from. Keep focused on this simple aspect of the situation and avoid being distracted by the complexities.
When your browser sends a request, where does it go? Does it get to your server? You may find that some of the requests are not going to the server you think they are going to: some other server may be responding.
Server logs and network sniffers can be very helpful, along with your understanding of the HTTP protocol and careful attention to the details of what is happening. It can be painstaking work but ultimately isn't very difficult if you have access to the systems and understand the fundamentals.
If there is someone there more familiar with the infrastructure (network, proxy servers, web servers, etc.) I would review the symptoms with them.
It is possible that your infrastructure includes a "transparent" proxy server. This is a proxy server that intercepts and potentially modifies communications that aren't explicitly directed to it. In some cases, they provide a response to the client that appears to have been sent by the server when in fact the proxy server has blocked the communication with the server and produced the response itself. They can include caches, so the response they provide might be from an old version of your script. But they would typically be dealing only with the HTTP requests and responses and would not be able to execute an old version of your script with new query parameters (if such is relevant to your script).
If there is a transparent proxy server in your environment, your infrastructure folks should be able to tell you about it, but sometimes such devices are installed without being well understood or the person who knew what it was doing leaves while it carries on. You can detect a transparent proxy by careful comparison of what happens at the browser with what happens at the server. In the absence of proxy servers (transparent or otherwise) there should be a one-to-one correspondence of requests and responses at both ends and neither requests not responses should be modified in transit.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^8: apache/perl caching problem
by ksublondie (Friar) on May 04, 2010 at 18:37 UTC | |
by ig (Vicar) on May 04, 2010 at 21:05 UTC | |
by ksublondie (Friar) on May 04, 2010 at 23:24 UTC | |
by ig (Vicar) on May 05, 2010 at 07:54 UTC | |
by Anonymous Monk on Sep 26, 2010 at 15:22 UTC |