Keep a cgi alive ? Or standalone ?

I have designed a web service as Paypal listener with HandleURL which works fine most of the time, but when the app has quit, it seems to take too long to start, and misses the Paypal post.

So, I need a way to keep the app alive all the time. How can I manage that ? I vaguely remember Greg mentioning that references can prevent an app to quit but can’t locate that.

In the wake of my issue, I thought I explore the standalone deployment.

So I uploaded a test program to my 1701 Linux host in the match-software.com space, navigated to it with the terminal and launched it with

./oiga --port=8080

It apparently runs, as the terminal stops displaying the prompt, but I don’t seem to be able to access the app.

http://match-software.com:8080

gets This webpage is not available ERR_CONNECTION_REFUSED.

I also tried http://107.155.86.205:8080 to no avail.

What am I missing ?

Could it be that the port 8080 isn’t freed fast enough by the system? In my experience this can consume some time.

Can you call App.Daemonize in your WebApp.Open event…

From the docs
“Converts the application from a regular console application to a daemon process that runs in the background on OS X or Linux.”

(Forgive me if your already doing this)

OK. I have set Daemonize and the app is running, but still, I do not seem to be able to find the proper URL to access it.

Now I understand why I kept using cgi until now. Standalone is not a piece of cake.

This is a shell startup script I’ve used in the past to start a Daemonizsed web app

./App --securePort=7201 --port=7200 --maxSockets=400 --maxsecuresockets=0

Maybe you could try adding the --maxSockets to your startup statement?

Thanks Patrick.

Yet, I still cannot seem to be able to access the app.

I can see the app running with ps but http://match-software.com:7200 does not display it.

The same app compiled for Mac run with the same command line on my machine, I access with http://192.168.038:7200 without a problem from the iPad.

Maybe a problem of firewall on 1701. I will have to ask Phillip about that.

Yes, it seems likely. It is normal that all server ports are closed by default.

OK. For the time being, I set the CGI app autoquit to false, which should ensure it remains listening all the time.

Does sound like it…

[quote=258866:@Patrick Delaney]This is a shell startup script I’ve used in the past to start a Daemonizsed web app

./App --securePort=7201 --port=7200 --maxSockets=400 --maxsecuresockets=0

Maybe you could try adding the --maxSockets to your startup statement?[/quote]
Just FYI, you don’t need to set the --securePort property if you’re setting --maxsecuresockets to zero. In fact, when you do this you’re having your app spin up a second serversocket and then not using it. They do consume memory and CPU cycles so you might want to leave these completely off.

[quote=258863:@Patrick Delaney]Can you call App.Daemonize in your WebApp.Open event…

From the docs
“Converts the application from a regular console application to a daemon process that runs in the background on OS X or Linux.”

(Forgive me if your already doing this)[/quote]
Don’t do this for CGI apps. it’s already done in that mode and you’ll have connection issues.

There was a reason I left that in but can’t remember now, I do have something in my email from 2013r4 talking about this. IIRC, something didn’t work right without that left in but it was a LONG time ago…

I thought we were talking standalone?
I don’t use CGI but I didn’t know that - thanks :slight_smile: Maybe the docs could be updated to reflect that for the Daemonize property