CGI file question

  1. 2 months ago

    Ralph A

    Jul 16 Santa Monica, California

    Can I safely assume the following:

    If a CGI Web app is already running when a user hits it, its CGI script will not execute. That is, the CGI script is run only when a user hits the Web app during a time when the app is not running (e.g., after AutoQuit stopped the app).

  2. Ralph A

    Jul 16 Santa Monica, California

    Put another way, can I assume that this error.log message only occurs if the CGI app crashed after the CGI script attempted to start it:

    Can't use an undefined value as a symbol reference at [...].cgi line 118.

    That is, I wouldn't see such an error coming from a CGI app that was running when the user hit it.

  3. Greg O

    Jul 16 Xojo Inc

    @Ralph A Can I safely assume the following:

    If a CGI Web app is already running when a user hits it, its CGI script will not execute. That is, the CGI script is run only when a user hits the Web app during a time when the app is not running (e.g., after AutoQuit stopped the app).

    The cgi script is always used, regardless of whether the app is running or not. If it’s not, it attempts to launch the app. It then acts as a conduit.

    @Ralph A Put another way, can I assume that this error.log message only occurs if the CGI app crashed after the CGI script attempted to start it:

    Can't use an undefined value as a symbol reference at [...].cgi line 118.

    That is, I wouldn't see such an error coming from a CGI app that was running when the user hit it.

    I usually see this when someone attempts to run the cgi script from the command line and not a web server.

  4. Antonio R

    Jul 16 Pre-Release Testers, Xojo Pro, Third Party Store Europe (Italy)

    Greg is right, but it can happen.
    Since it acts as conduit if the web app crashes (URLConnection?) you can get similar errors since the script is in some "undetermined" situation.

  5. Ralph A

    Jul 16 Santa Monica, California
    Edited 2 months ago

    @Greg OLone The cgi script is always used, regardless of whether the app is running or not. If it’s not, it attempts to launch the app. It then acts as a conduit.
    I usually see this when someone attempts to run the cgi script from the command line and not a web server.

    I only (and always) see this Line 118 error when the user hits the app with their browser and they get an Internal Server Error 500. I have always assumed it meant that the app crashed at Line 118 while starting up, after having not been running. So I've been planning on using AutoQuit=False and running a parallel CGI app that periodically checks the status of the app in question, and stops and restarts it when it sees error 500.

    Usually mobile phone users get into this situation.

  6. Ralph A

    Jul 16 Santa Monica, California

    BTW, this Line 118 problem has been verified with a very simple almost-naked CGI app a while ago: Feedback Case #54665. No command line stuff necessary to make it happen.

  7. Antonio R

    Jul 16 Pre-Release Testers, Xojo Pro, Third Party Store Europe (Italy)

    Ralph is an app with a Timer?

  8. Ralph A

    Jul 16 Santa Monica, California

    @Antonio R Ralph is an app with a Timer?

    The verified app submitted to Feedback has an App object timer that allows the developer to stop and the restart the app easily, by just renaming the CGI file and then reverting it back a few seconds later:

    Dim f As FolderItem
    f = GetFolderItem("")
    f = GetFolderItem(f.NativePath + Lowercase(App.ExecutableFile.Name) + ".cgi")
    If (f.Exists() = False) Then
    App.Quit()
    End If

    That is essentially the only code in the entire app.

  9. Ralph A

    Jul 16 Santa Monica, California

    I was hoping that a CGI script Line 118 error, being that late in the script, might imply that the app wasn't running before that script started.

  10. Greg O

    Jul 16 Xojo Inc

    @Ralph A I was hoping that a CGI script Line 118 error, being that late in the script, might imply that the app wasn't running before that script started.

    The error you gave:

    Can't use an undefined value as a symbol reference

    Means that the request that came in was incomplete.

  11. Ralph A

    Jul 16 Santa Monica, California

    @Greg OLone The error you gave:

    Can't use an undefined value as a symbol reference

    Means that the request that came in was incomplete.

    Well, I really don't understand that. That error has been commonly discussed on this forum. And Xojo Support confirmed it happening easily with a very simple Web app submitted to them, using a mobile phone. Reading access.log, I suspect this happens only when the app isn't running, though can't be 100% sure of that. I was hoping you would confirm that the script wouldn't reach Line 118 if the app is already running, validating my suspicions. Apparently that's not the case.

    I may just deploy the app with AutoQuit=False and see if that puts an end to these errors at Line 118.

  12. 9 weeks ago

    Antonio R

    Jul 16 Pre-Release Testers, Xojo Pro, Third Party Store Europe (Italy)

    @Greg OLone Means that the request that came in was incomplete.

    ... or response.

    You got the same if your app crashes.
    I don't know the reason for, but this is what happens.

    Probably the app start as requested (or is already running) then it crashes and the "link" becomes invalid and this condition is reported as "undefined value"

  13. James D

    Jul 17 Pre-Release Testers, Xojo Pro Europe (Switzerland)

    @Ralph A The verified app submitted to Feedback has an App object timer that allows the developer to stop and the restart the app easily, by just renaming the CGI file and then reverting it back a few seconds later:

    Dim f As FolderItem
    f = GetFolderItem("")
    f = GetFolderItem(f.NativePath + Lowercase(App.ExecutableFile.Name) + ".cgi")
    If (f.Exists() = False) Then
    App.Quit()
    End If

    That is essentially the only code in the entire app.

    I have to say I have serious doubts about putting that kind of code into a CGI application in the first place. A CGI is part of a process, it is not an independent application, pull it down unexpectedly and all bets are off, you should not expect a clean cut termination in such a situation.

  14. Ralph A

    Jul 17 Santa Monica, California

    @James D I have to say I have serious doubts about putting that kind of code into a CGI application in the first place. A CGI is part of a process, it is not an independent application, pull it down unexpectedly and all bets are off, you should not expect a clean cut termination in such a situation.

    Here's where this technique is outlined in detail: http://www.dev.1701software.com/blog/2013/09/08/upgrading-xojo-cgi-apps

  15. James D

    Jul 17 Pre-Release Testers, Xojo Pro Europe (Switzerland)

    @Ralph A Here's where this technique is outlined in detail: http://www.dev.1701software.com/blog/2013/09/08/upgrading-xojo-cgi-apps

    So what, the does not mean it is a good idea.... and it does not seem to work for you.

    A CGI application is running under the supervision of some kind of server, it is responsible for managing that instance and suddenly you pull it down without any indication to the hosting application of what is going on.... a 500 error is exactly what you should expect coming back for the server. Your CGI disappeared and the server has not go a clue what happened.

    You are not even checking if a request is being serviced at the point you pull down the application....

  16. 7 weeks ago

    Ralph A

    Jul 28 Santa Monica, California
    Edited 7 weeks ago

    @Ralph A I may just deploy the app with AutoQuit=False and see if that puts an end to these errors at Line 118.

    This seems to have ended all Line 118 CGI script errors, and their associated Internal Server Error 500 responses. They only seem to happen when hitting a Web app that has quit due to lack of sessions, and mainly when hit with an iPhone. AutoQuit=False seems to have stopped this. I have a second CGI app that watches for an Internal Server Error 500 response from the first app (hourly), ready to kill and restart the first app if it gets such a response. It has not needed to do that. Been running this way for about 10 days now.

  17. Phillip Z

    Jul 29 Pre-Release Testers, Xojo Pro Florence, SC

    The whole point of that technique is the CGI keeps handling requests despite you wanting to terminate the Xojo app that is running. So you let the Xojo binary decide for itself it should quit when the CGI disappears (with by virtue of disappearing is no longer serving requests). This gets you out of an issue where you can't shut your app down because new requests keep spinning up the old version before you have time to replace it.

    It is a fix for a specific use case.

  18. Ralph A

    Jul 29 Santa Monica, California

    @Phillip Z The whole point of that technique is the CGI keeps handling requests despite you wanting to terminate the Xojo app that is running. So you let the Xojo binary decide for itself it should quit when the CGI disappears (with by virtue of disappearing is no longer serving requests). This gets you out of an issue where you can't shut your app down because new requests keep spinning up the old version before you have time to replace it.

    It is a fix for a specific use case.

    I think this was meant as a reply to James Dooley.

  19. Phillip Z

    Jul 29 Pre-Release Testers, Xojo Pro Florence, SC

    yes

or Sign Up to reply!