Very strange behaviour - advice needed

[Ian Hobson]

Hi all,

I have a php system that generates some quite large (200K-800K,  4-18 
page) .pdf files. It has been working fine for months, on Ubuntu/nginx 
07.67 and Windows Apache/2.2.11 (Win32) PHP/5.3.0

Then a recent change involved making some of the images in the .pdf 
files slightly larger, and involved moving the production server (from 
Ubuntu 10.04 with nginx to Apache 2.2.under Ubuntu 10.10.

I immediately started getting reports of  black screens when showing the 
PDF files. Investigation showed that
     The log showed the correct .pdf url
     The time taken was consistent with the .pdf being generated (4-8 
seconds).
     The content was displayed as a pdf (to the headers sent are pdf 
headers).
     The content was actually the initial log-in screen as if the 
session data was not found.
     the PDF is generated in response to a javascript button that 
executes code like this...

function dopopup(what,act) {
var url = 'http://sopsystem.anake.hcs/'+ act + '/' + what + '350.pdf';
var win = window.open(url,'_blank');
win.focus();
window.setTimeout('location.reload(true)',8000);
}
This is then converted using
     location ~ \.pdf$ {
         rewrite ^/(email|print)/(quote|ack|amend)(\d+)\.pdf$ 
/index.php?view=$2&act=$1&id=$3;
     }
and it is served in the new window.

Further investigation has shown that the session is indeed empty when 
this happens.

I am left wondering why the session sometimes cannot be found when 
opening a new window, but usually works just fine.

Having never had a problem with nginx before or on the test setup, I 
swapped Apache 2.2 out and put nginx in, and the level of reports has 
dropped, but not gone away.

I have two development systems. A Windows Apache 2.2 system for 
development and a Ubuntu nginx VM system for staging before moving to 
production.

The Apache 2.2 system is a standard WAMP install.  Here some documents 
always fail as above, and some always succeed. A large one failed - and 
appeared to take
Apache down with it. So I stopped all processes (which took some 
considerable time) and start them again.  Then the one that failed, 
worked! More puzzlement!

So I tried to test the nginx side.

The a large PDF (17 page) failed. So I opened the base record to see if 
there was any obvious data error. There wasn't, but I saved it anyway. 
Now it works. I can create PDF files
from all the other records on Nginx side now including the one that 
failed a moment ago.

So I rebooted the nginx machine and tried again. This would ensure 
everything was fresh.
This time I was told the .pdf file was corrupted and could not be 
repaired. Looking at the source it appeared to be a valid .pdf file.
So I hit refresh in the browser. And the pdf displayed properly.

Closed the window and triggered it again from the link - it works fine.
Others also work fine.

Rebooted the VM server and clicked the link again - this time the new 
window displayed the login screen as the login screen ALTHOUGH THE URL 
WAS THE .PDF.  This is what I would expect if
the session no longer existed. Conclusion - sessions are wiped when 
fastcgi php starts. Reasonable.

So closed windows, went back to the main screen, logged in and called up 
the PDF again. It worked this time.

So I rebooted the server, logged in and requested one of the ones that 
had never failed. It failed "PDF corrupt".
So I hit refresh and it appeared - all 18 pages of it.
Go back to the first one that failed - it works first attempt.

Has anyone any idea what might be going wrong, or any suggestions as to 
how to debug it further?

The only thing that makes sense with what I have observed that that 
something is getting messed up and crashing on the first call for a PDF 
file, and the recovery processing is actually recovering.
But is it the PDF library, the PHP fast_cgi set up or what? And how can 
I detect which?

All input gratefully received.

Ian














I've Googled and found nothing helpful.  Maybe my Goole foo is low today.

Has anyone any idea what might be happening?














-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20110328/055a069e/attachment.html>