Hi,
I have web services running as Xojo webapp.
how can I solve the connection problem that produces the blocking error “application launched but unable to connect using port …”?
the problem occurs by choosing the automatic port assignment, but also by choosing a specific port.
thank you.
That error is usually caused by the app already having been launched but is either too busy to respond or is hung.
thank you.
but how do I get out of this impasse?
I have noticed that if the connection to the webapp fails (e.g., due to problems on the network), the next execution shows the error.
In this case, how can I detect and delete the process?
the only way I’ve found is the manual killing.
or is there another way to prevent the webapp from still wanting to use that port?
The correct way is to figure out why your app is locking up. Usually caused by either a tight loop or the app running out of RAM.
The last lock was simply due to a network problem.
I have executed the request of a common list with 40 elements without any parameter.
This request is as simple as frequent in my project, but this time it ended with a network error message from the server.
The request was relaunched immediately after, but it was blocked due to the usual problem (Application launched…unable to connect…).
I would like to leave CGI (which it seems we will be forced to leave anyway, soon).
but my SSL applications must run on a server where only port 443 is open on the internet.
it is not possible to open other ports on the internet.
so my standalone applications work in the intranet, but aren’t reachable via internet.
how to solve it? it will be a problem for the future too.
i can’t force my customers to open other ports on the internet.
they leave the ports closed and fire me.
Normally you would want to still put a web server in front of a stand-alone app acting as a reverse proxy / load balancer anyway to help protect it from the Wild West that is the internet.
Requests still come in on port 443, are handled by the web server (let’s say Apache) and then “proxied” over to to your app for processing.
If, for performance or scalability reasons you wanted to have more than one app handling requests, that’s when you need the load balancer aspect.