How many instances (processes) of the app is expected to run on cloud? I’d expect it to be one, but directly get four.
Result: Four processes for the application is running.
This was discussed earlier in How many instances of the application should XC spawn? - back then one instance per app was expected. Does the same apply now, or is four normal?
You get one instance per vCPU.
Thanks.
Does that also mean that:
In event handler for WebApplication.Opening we create a ServerSocket and start listening on a port.
Yes, 1 instance per vCPU on the standalone apps on Xojo Cloud.
If you are using a ServerSocket, you’d need to make sure to have a way (via a file, sqlite db, etc) to know which port(s) had already been open. That’s correct, only one instance should be listening on a given port.
Yes. The first one will succeed and the second will fail. That said, I urge you to evaluate your need and consider using an http api through HandleURL if you can. Adding a second ServerSocket instance to your app (the built-in one being the first) can severely degrade the performance of the web app overall. The ServwrSocket does everything on the main thread, which means that while it is accepting and negotiating connections with its clients, it is blocking the web app from dealing with its own. Also, you don’t get any of the protections from bad actors that you otherwise do with the Apache Load Balancer running in front of your app.
It’s also important to remember that unless you’ve built your app to handle this, if the instance that is listening crashes, the other one doesn’t just start listening in its stead. The crashed app will restart on its own relatively quickly and if the port is available, it will start listening again.
I’ve got a solution hosted on XojoCloud, and the WebApplication appears to be launching multiple instances - and I’m wondering the best approach to centralizing a common variable. I have a global variable that I’d like to update and have that update be reflected across any/all running (and starting) instances of the WebApplication. Any best practices on this? Thanks!
Depending on what the value is for, you could write the ultra-global value to a file on disk.
Another option would be to use a tool like my app Lifeboat to have a little more control over how your app runs.
You could store the variable in a database.
Hi @Hanif_Saad and thanks @Tim_Parnell, I appreciate the responses! This confirms that I’m not overlooking anything obvious (and easy, and built-in). I may start white-boarding a possible way of using sockets and registering instances for some crazy solution that would allow me to create a tunnel to share vars thru… (yes, it sounds crazy, and it probably is)
Not necessarily crazy. Depending on your topology and needs, you may be able to avoid registering instances using various methods such as:
I’ve never done the above with web apps yet, but have with “sharing data” between Xojo desktop and/or console (helper) apps. Or apps not even on the same LAN in the case of RabbitMQ.
I don’t believe that a UDP multicast will work within the XojoCloud environment.
You can call the instance trough it’s port and urlconnection. You just need to onow which instances with which ports are running.
In the handlurl event you can check for localhost.
We just use a table in the database that all instances would be connecting to. Multiple instances on Xojocloud not by design though may indicate an issue with your application. Typically it only spawns another copy when the current copy has error-ed out in some way.
On modern xojocloud, there are always multiple copies of each app equal to the number of cores on your server. They are load-balanced behind Apache and they are set up to automatically respawn if the instances crash or become unresponsive.
Aw yes but your masking what I am talking about. The key to what I said was “not by design”. In your case Web2 Xojocloud by design has multiple instances. But if the individual apps themselves are re-spawning then an app has crashed or become unresponsive. Which is something that does need to be diagnosed and addressed.