in reply to Re^6: Broken image link when calling CGI from img tag
in thread Broken image link when calling CGI from img tag

As I posted previously, existence for the file is checked before calling the redirect.

But you haven't shown what happens if the file doesn't exist. You haven't told us if there are any mechanisms on your system that might delete files.

All in all you told us little about your system (and most importantly, have shown us little actualy code), and haven't headed the advice to look into the access and error logs.

Asking general questions to solve a specific problem seems rather inefficient to me.

Perl 6 - links to (nearly) everything that is Perl 6.
  • Comment on Re^7: Broken image link when calling CGI from img tag

Replies are listed 'Best First'.
Re^8: Broken image link when calling CGI from img tag
by lintunen (Novice) on Jul 28, 2010 at 09:59 UTC
    It seems that everybody is missing the point or I have not described the problem properly? The image IS getting generated just fine, there are no errors in the error logs - I mentioned in my initial post that a subsequent refresh is required in order to make the image appear in the browser and I am not sure what measures to take to make the image load the first time the page is loaded. (I also mentioned the code works on Apache, but not IIS.) I did show what I believed to be the important line of code and described how it was called, I'm sorry if that was too vague.

      Note that the file might have been only partially written when you check for it, for example if you have a filehandle that is still open to the image file, which still buffers data. Explicitly close or undef the filehandle to force writing all data to disk maybe before sending the HTML out that references the image.

        And finally I was able to solve my problem by creating a new thread http://www.perlmonks.org/?node_id=856002 and implementing backticks instead of using a piped open.

      The image IS getting generated just fine

      You've said that before, but never mentioned when it is generated just fine. Which is kinda important, when it comes to timing issues.

      (Note that a check with -e only checks if the file itself exists, not if it is fully written, a valid image, and readable.)

      I am not sure what measures to take to make the image load the first time the page is loaded.

      Point is, if the image is generated in time for the page load, there shouldn't be any measures to take. Which means that something's going wrong, and so far there's no conclusive explanation of how and why stuff fails.

      And fixing results when you don't know what's wrong is like trying to hunt birds, blind-folded and with only a sling.

      I also mentioned the code works on Apache, but not IIS.

      You did, but that doesn't necessarily give us a clue about what's wrong, or how to fix it.

      One thing you can do is to run the a client request, including image loading, both through Apache and IIS, and record the TCP streams. Then you can compare the two, and learn at which level they differ, and why the browser doesn't display the image.

      Perl 6 - links to (nearly) everything that is Perl 6.

        I had a further think about the issue and threw in a "sleep" function and as sleep allowed the page to render correctly on first load, I am guessing the issue is that the call to the piece of code that generates the image isn't completing before code execution continues.

        The piece of code that generates the image file is done by passing an input file to R:

        open($R, "|C:/Progra~1/R/R-2.11.0-x64/bin/R CMD BATCH " . $R_FILE) or +die $!; close($R);
        (This line of code was ported from Linux). I have tried a few various ways to try to make execution wait the image generation to finish but perhaps I am going about it the wrong way because nothing I have tried works or that it's a problem specific to the Windows environment. Do you have any suggestions on where to go from here?

      there are no errors in the error logs

      So check the access log, see how many bytes were served, compare to bytes served on reload, then compare the raw HTTP