Because FastCGI never really worked right in web edition, and we removed that code from the .cgi file this spring.
Ah - thanks.
Mark, please test this in b8 when it comes out.
Will do.
The speed difference between CGI and standalone is so significant that eventually you will want to consider it. The latest CGI issues seem to be affecting most everyone I know of using R2.
That is the healthy debate I was referring to.
Are you referring to the issues discussed in this post?
Confirmed - did not fix the spawning of many myapp.cgi commands and associated httpd commands.
I suspected CGI to be slower. But in terms of usage, it is convenient because it runs whenever the user calls the cgi.
I have no religious issues with standalone (healthy debate), but one of practical convenience. Standalone must be started each time the system starts, right ? How do you achieve that in a convenient way ? I do not feel like running my programs manually though SSH …
depending on the host
- crontab
- init.d
- launchd (if you happen to host on OS X) as you can make it launch whenever it’s not running
there’s plenty of options and this is only a handful
[quote=116056:@Michel Bujardet]I suspected CGI to be slower. But in terms of usage, it is convenient because it runs whenever the user calls the cgi.
I have no religious issues with standalone (healthy debate), but one of practical convenience. Standalone must be started each time the system starts, right ? How do you achieve that in a convenient way ? I do not feel like running my programs manually though SSH …[/quote]
I’m working on a PHP script that will launch a standalone and then redirect the user to it. Should be best of both worlds.
Again the speed difference is significant. Email me privately if you want to see an example.
Have you compared CGI to Standalone in r2? We’ve made significant improvements in the performance of CGI and they are very close to one another.
It would be more helpful to everyone here if you would mention specific Feedback cases. A blanket statement like this is a bit misleading.
[quote=116063:@Norman Palardy]depending on the host
- crontab
- init.d
- launchd (if you happen to host on OS X) as you can make it launch whenever it’s not running
there’s plenty of options and this is only a handful[/quote]
Crontab would not work unless the system starts at a precise hour everyday. I was not aware of init.d ; the issue here is that cgi is simple to implement, when standalone documentation is so sparse, I have needed to ask here and get assistance by Brad Hutching (thanks) to see how to run these programs. A good how to would be welcome.
Sure, for newbies there is now Xojo Cloud, but I feel WE could be better documented. This example of init.d which seems from what my feeble mind can comprehend like a list of startup items should be provided in the docs, for instance.
[quote=116066:@Phillip Zedalis]I’m working on a PHP script that will launch a standalone and then redirect the user to it. Should be best of both worlds.
Again the speed difference is significant. Email me privately if you want to see an example.[/quote]
I had mentioned such an idea in some of my posts. It is great that you decided to create that PHP script 
As soon as R2 hit I am spending tons of time each day helping people kill ghost CGI processes. The overhead of the entire CGI stack is inherit to the process though so I don’t see how it could ever be that close. For most people CGI seems to work well enough.
[quote=116073:@Greg O’Lone]
It would be more helpful to everyone here if you would mention specific Feedback cases. A blanket statement like this is a bit misleading.[/quote]
Well to be perfectly honest I don’t use feedback. Also I’m not going to submit issues on behalf of my customers. I think the issue has been raised? you are aware of it? How does posting feedback numbers help? It sounds like a fix is potentially possible in 2.1 but not likely. Not sure what you mean by blanket statement. I’m saying most everyone I know using R2 is having issues with CGI. I don’t know how to qualify that any better than trust me?
Not trying to raise a stink with my last comment. Just saying theres 70 something replies of people discussing an issue that you are seemingly aware of. Seems unfair to single me out just because I said I know of people having issues as well. Sorry if I come off coarse this issue has been annoying to the say the least. I’m moving everyone I can to standalone. The CGI trouble is not worth it anymore.
I have been afraid to kill the CGI processes, because I am never sure if that would impact the running application. Do you have a way to tell whether or not killing a particular process would impact a running app?
Unfortunately I have been resorting to maintenance interruptions where I kill the whole app, or I restart the whole server - both are rally bad options.
You can kill the CGI’s usually with no impact on the end users. Those are just child processes of Apache. A new one will get spawned up at the next user request. The background Xojo app will be able to discern the proper session based on the session url’s used.
If you kill the actual Xojo app then everyone loses their session.
Excellent - I will give that a try. Thanks.
I suspect a configuration problem on the servers then. We’re not having issues like that on Xojo Cloud.
How can you make a statement like “The latest CGI issues seem to be affecting most everyone I know of using R2” then? If there are issues in r2 which you (or your customers) have run into then the only way to get them fixed is for someone to report them. My concern Phillip is that users trust you as a knowledgable member of this community when it comes to Xojo Web. When you make a statement like this, everyone thinks that r2 is unusable for anything.
There are four issues that I am aware of that could be causing users problems with r2, all of which have been fixed for 2.1:
- 34438 Session.Quit is not doing its job and is actually extending the life of Sessions.
- 34307 The security change we made for apps shown in an iframe or a WebHTMLViewer on another app is preventing users from showing apps on other servers.
- 33967 HandleSpecialURL is returning everything gzipped, even if the client didn’t ask for that.
- 34462 WebDialogs added directly to a WebPage become unusable after the Close method is called.
As I said, these don’t affect everybody, and there are workarounds for #1 and #4. I’d also encourage you (and your customers who have access to the betas) to try out beta 8 when it’s released.
It’d work with the right “start time spec” like * /1 * * * and that runs a script that sees that your server is up once a minute
Done
Yes it could leave a gap where your server starts & dies right away where its not up
Not ideal but it does work
It’s a very common / standard way to run start up scripts
http://lmgtfy.com/?q=linux+start+up+script
Stuff like this varies from OS to OS
Init.d is a standard Unix start up mechanism - its been around a VERY long time & is common even on LInux
If you’re administering or setting up a server you should know about these things
Or use Xojo cloud so you can avoid having to know everything about everything involved
Or host with Phillip so he sets it up
[quote=116106:@Greg O’Lone]When you make a statement like this, everyone thinks that r2 is unusable for anything.
[/quote]
That’s fair and I’m sure some people are doing just fine. I just know that once R2 hit there has been a massive influx of internal server errors and ghost CGI processes. Some of these are apps that have been running smoothly for 6 months or more without issue.
Standalone is working fantastically though and at the end of the day its a better solution than old CGI. Thanks for following up on these issues.