Currently, web apps are leaking memory and at some point will crash causing troubles. In small VMs, in few hours, so I wish to try to detect abnormal use of the memory over time, and move new connections to other instances not yet broken, and quit the problematic ones while firing new ones. The problem is that I wish to stop serving new sessions in the current one when I detect such condition, and wait everybody finish their tasks until the last user connected finish his job. That means: At some point, I wish to stop serving new connections, but letting the current users finish their jobs, and when I get ZERO active sessions, launch another app instance and quit.
How’s the best way to achieve such workaround? Suggestions?
What about usertimout: https://documentation.xojo.com/api/web/websession.html#websession-usertimeout?
As for checking conditions of the app, you could write a monitoring app?
tasklist | find "app.exe"
Works on windows commandline to check the memory usage of your app. I’m unsure of the MAC/Linux command.
I think you didn’t get it. I mean internally in the app.
I can try to find and infer the messed state IN the instance consulting the memory use. As I’m a Xojo Web newbie, how do I turn ON a “from now on deny new sessions but keep serving the current ones”?
I think that we don’t have a “Xojo way” of doing it, but probably I need to set a flag “block new sessions” and execute a Session.Quit right from inside of the WebSession.Opening event. The bad thing is that probably each attempt will leak a bit too.
Sorry I must’ve not explained very well.
- Issue 1: Detect abnormal memory overtime
- Use a timer that fires a method. This method checks current memory usage on server. Example: Use a Shell command to get current memory of application.
- Issue 2: Move connections to another instance
- Issue 3: If Memory > X Do not allow new connections.
- The previously mentioned method returns the memory amount. Set App.AcceptingConnections = False
- Issue 4: Launch another app instance.
- When session count reaches 0 run another shell command (actually. Would probably best to launch an outside script.) App.exe stop. App.exe start.
You can do this in HandleUrl. When you want to start rejecting new sessions, you can redirect them elsewhere like this:
Response.Header("Location") = otherUrl
Response.Status = 302 // moved temporarily
Return True
2 Likes
Hmmm. As the instance is “in bad state” what’s the way to serve just some status like 403 Forbidden?
A
Response.Status = 403 // Deny. Forbidden.
Return True
Is enough?
Still in doubt, no new session will be started? Will start just in case of a 200?
Can I call WebSession.Quit right from inside of the WebSession.Opening event and abort it?
The URLs being handled by the current sessions should continue being served as always, only new sessions must be denied.
As far as I noticed, it does not work. Will block the entire server, not just new sessions.
Returning True is what’s blocking. Basically you are saying “I handled it”.
You can call Session.Quit.
And they should. The only things that are sent to HandleUrl are root-level urls and things not handled by the framework.
It would be helpful to see your code in that event.
I think I need to mature a bit more my understanding on how things are supposed to work in the current design, it’s not obvious. For example; the session.opening event occurs when session starts, but the session.closing is not the other way around, seems a propagation of app.closing instead of the end of the session. A refresh of the browser seems to orphanize sessions instead of reconnecting them. I think I’ll need to play a bit more. I had the impression that sessions are leaking, new ones starts and older ones seems not close, but I may be wrong, just not understanding the engine yet. But as we know, something is not ok. I hope you can find it and fix it. Good luck.
A bit more info.
WebSession.Quit
Seems not firing any kind of “Session ended” event, looks like as just setting some internal status for a “future”, if such opportunity happens, send a “disconnected” event. After a websession.Quit, if I refresh the browser, it sends a late “disconnected” event, if I do nothing, it just sits there quiet.