Standalone vs CGI: Some questions

I hear on this forum that XDC announced that CGI will be dropped for Standalone.

  1. Does this mean that the IDE will only build a Standalone app, giving us no option to build a CGI app?

  2. Right now, with CGI apps, I can build them so that if I have to kill the app (say it’s unresponsive for some reason, producing an Internal Server Error 500), I can do that with a simple SFTP app on my mobile phone. This is done by simply renaming the CGI file, and then renaming it back. A piece of Timer code sees the missing CGI file and kills the app. When the CGI file is renamed back to normal, the next user to hit the app starts it again. I don’t need access to the command line to handle such a situation. Will a Standalone app allow for simple killing and restarting from a mobile phone?

  3. Also, the Timer code mentioned above will kill the CGI app when SessionCount drops to 0. This allows it to automatically restart during unresponsive situations described above (I always have found that unresponsive CGI apps soon lose their Sessions). But suppose a Standalone app becomes unresponsive. Can it be configured to die and restart? I can’t imagine how that would be done, as it has no access to the command line when dead. At least the CGI app starts up again when the next user hits it.

One of the best ways of managing standalone apps is by using the server operating systems built in methods for managing daemons. Most servers init systems include tools which are capable of restarting dead app instances automatically. I use this method myself personally and have found it quite solid and reliable, especially compared to any sort of manual app monitoring and restarting scheme.

I host my apps on linux type OSes and many of those use either “systemd” or “upstart”. Both of these systems will ensure your standalone apps launch at startup under the conditions you desire with control over the environment and many other helpful management features including restarting dead instances.

Macs have “launchd” - which I believe is similar to the above. I cannot comment on Windows based servers.

On Windows, it is quite simple also.

  • Build the executable and install it on the server as desired.
  • Then, open a terminal window with elevated priviledges.
  • Type sc.exe create <new_service_name> binPath= “<path_to_the_service_executable>”, replacing with the specific executable information, accept.
  • Then with the management console, you can define the start behavior (automatic, manual, disabled), recovery in case of failure, etc. for your new service.

all in all, a 2-minute thing.

On Linux Webservers I fell in love with Webmin. It can monitor itself and anything you configure. So all my Standalone Servers or Services are checked periodically every 5 Min and eventually restarted if they do not respond with correct status code.

Thanks to all here who replied. Good info. Of course all this will depend on how whether Xojo Cloud or allow me to control such stuff. Right now, Xojo Cloud is CCGI only, and has no Standalone Do It Yourself.

You have time. Xojo said they will keep CGI server around and I’m sure ServerWarp will too.

Right. Xojo Cloud will still provide cgi support for older IDEs for the foreseeable future, but once we release the new web framework, those IDEs will only build and upload standalone apps.

Thanks for the clarification, Greg :slight_smile:

With ways for developers to configure that server to automatically restart a stuck Standalone app, etc?

I guess it largely depends on what you mean by “stuck.”

Unresponsive. Internal Server Error 500. Stuff like that.

There are some things that we can do about that. The least of which is to set up the load balancer to stop routing new sessions to instances which don’t respond quickly enough or respond with http server errors.

That said, over the years I’ve seen many user-caused situations which make their apps to respond badly and could easily trigger this mechanism. For instance, having a long running query that doesn’t yield could cause a timeout or an unhandled exception can cause a 500 Server Error response.

All of this is hypothetical at this point though. We have to get most of the new web framework done before any of the Xojo Cloud work can be started.

Hi Greg,

Interesting comment as I was under the impression that most of the new web franework has been done. From your comment that appears to not be the case ?


I was thinking more of cases where an iPhone user gets an Internal Server Error 500 because of its “deep sleep” problem ( But maybe that only happens with CGI apps and not Standalone apps?

[quote=435781:@Stephen Pardoe]Hi Greg,

Interesting comment as I was under the impression that most of the new web franework has been done. From your comment that appears to not be the case ?[/quote]
What I meant is that the work on Xojo Cloud can’t be done until the new web framework and IDE integration is complete. It’s just a matter of logistics.

Sorry, I’m confused, are you saying that you won’t build apps that will run under Apache anymore?

No. We are saying that they just won’t be CGI any more. You’ll still be able to use Apache as a front-end.

how, with Apache? even now, without CGI?

Just like you would with apache sitting in front of tomcat:

Fair enough.