Open files

 
Post new topic   Reply to topic    Aprelium Forum Index -> FastCGI/CGI
View previous topic :: View next topic  
Author Message
ccs
-


Joined: 02 Apr 2005
Posts: 101

PostPosted: Wed Jan 23, 2008 9:09 am    Post subject: Open files Reply with quote

I have a number of CGI applications (if it matters, these are compiled executables) that open a text file to input the page's html code and displays it in an iFrame. I just realized that if the user navigates away from the page that embeds the output from this CGI before the CGI has completed, the text file remains 'open' and hangs the page. If you try to access this page after this happens, you get an error 500 in the iFrame area because the CGI app can't read from the text file.

After looking through the server config, I see there is a time-out setting for CGI scripts. If I set this to 5 seconds, the problem is minimized to an acceptable level.

However -- I don't really know what the impact is by changing this setting. The programs are pretty fast, but there is a noticeable delay when they run. (an impatient user is likely to click and reclick the submit button, or just leave).

Can someone give me a little more detail into the potential drawbacks of setting this value to say, 5 seconds, or 3 seconds?
Back to top View user's profile Send private message
pkSML
-


Joined: 29 May 2006
Posts: 881
Location: Michigan, USA

PostPosted: Thu Jan 24, 2008 3:09 am    Post subject: Reply with quote

It seems you answered your own question. Obviously, the CGI program must perform a file lock on the text file. While the first instance is hanging, the second instance can't read the document again because the CGI program's already running with the file lock.
_________________
Stephen
Need a LitlURL?


http://CodeBin.yi.org
Back to top View user's profile Send private message Visit poster's website
ccs
-


Joined: 02 Apr 2005
Posts: 101

PostPosted: Thu Jan 24, 2008 4:15 am    Post subject: Reply with quote

Quote:

it seems you answered your own question. Obviously, the CGI program must perform a file lock on the text file. While the first instance is hanging, the second instance can't read the document again because the CGI program's already running with the file lock.

Not exactly. The file is open for shared, read-only access. There are no other locks on it. What is happening, it appears, is that the CGI gets left in "limbo land" if the user navigates away from the page before the CGI has a chance to complete. This would be the case regardless of whether there was a file involved or not. With the default of 30 seconds, a user could very easily get multiple error 500s thinking that the server wasn't responding.

By changing the time-out value to 8, I seem to have the problem "solved" for all but the really-really impatient user. I guess I'm going to have to do some load testing though to see if this will stand up to heavier use. Fortunately, these applications are not going to be hit too frequently.
Back to top View user's profile Send private message
aprelium
-


Joined: 22 Mar 2002
Posts: 6800

PostPosted: Sun Jan 27, 2008 6:00 pm    Post subject: Reply with quote

ccs wrote:
What is happening, it appears, is that the CGI gets left in "limbo land" if the user navigates away from the page before the CGI has a chance to complete.


That's what happens and there is unfortunately no reliable way for servers to know that the browser is no more displaying a page (or that the visitor pressed Stop in the browser).

Some browsers will immediately stop the TCP connection and this may take up to 1 or 2 seconds to have the information propagated to the server. Some others will keep the connection opened and will not acknowledge the data they continue to receive from the server. So the server will have to wait until the CGI timeout or the TCP stack reports a connection problem (whichever happens the first) to stop the process.

As a general rule, we recommend that your CGI application do their job quickly. Your CGI applications should also process error codes and have a way to not block. In other words, try making opening files a time limited operation: if the open() hangs more than a few seconds, the CGI should report and error and exit in a clean way.

We can offer a better suggestion if you can post your source code (or at least its major parts where we can see the structure of the application: file opening, file reading, processing, etc...).
_________________
Support Team
Aprelium - http://www.aprelium.com
Back to top View user's profile Send private message Send e-mail
pkSML
-


Joined: 29 May 2006
Posts: 881
Location: Michigan, USA

PostPosted: Sun Jan 27, 2008 6:38 pm    Post subject: Reply with quote

aprelium wrote:
We can offer a better suggestion if you can post your source code (or at least its major parts where we can see the structure of the application: file opening, file reading, processing, etc...).


If you need to post large amounts of code, you might consider The Code-Bin.

Add your code
_________________
Stephen
Need a LitlURL?


http://CodeBin.yi.org
Back to top View user's profile Send private message Visit poster's website
ccs
-


Joined: 02 Apr 2005
Posts: 101

PostPosted: Sun Jan 27, 2008 9:08 pm    Post subject: Reply with quote

Quote:

We can offer a better suggestion if you can post your source code (or at least its major parts where we can see the structure of the application: file opening, file reading, processing, etc...).

Unfortunately, its all proprietary and unless you were familiar with the compiler I use (not a scripting language) it probably wouldn't make much sense anyway.

I've trimmed down the processing, and shortened the CGI time out values to a point that things appear to work about as good as I can expect.

Thanks for the input though.
Back to top View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Aprelium Forum Index -> FastCGI/CGI All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB phpBB Group