Here you go. Thank you for wasting your and our time. This thread was ment to handle a specific topic. If you want to complain about Xojo policys (again) then open a new one, please.
For me I can say: Xojo is great tool in a lot of cases, but I’m no Xojo fanboy. We have a vendor-lock-in-effect here, so that we cannot switch the base of our business from one second to another. Thats why I just search for pragmatic solutions for problems I have to accept that they would stay until forever.
That doesn’t mean, that I am happy with the decisions Xojo Inc. made, but that means, that I am realistic enough to deal with it.
Your strategy is simply to complain wherever you can. It’s not the first time, that you take part in a thread without having the target to help, but only to rant around. This is extremely annoying.
Thats why I tell one last more:
We all know you’re angry. You’re disapointed. You were forced to rewrite your applications after you’ve put trust and time into Xojo. Many of us feel the same, be sure.
But: it’s time to move on. For you, for us. We have to make the best out of this situation. Complaining was a strategy, that didn’t worked, so maybe consider changing your strategy or simply leaf us alone with always-repeating-opinion.
(sorry for that “Dude” above. I really try to stay calm and friendly, but you’re making this hard sometimes.)
You are right in some points even if the behavior of xojo inc in this case is in my eyes more than unprofessional. Never mind.
To get back to the Issue: after testing it we found no other solution. Restarting is the only one. Even I am really in love with the concept of xojo. That’s why I am so angry at all. Money is only one part of live.
Stupidly this problem comes also up for our devices with a single Server means the Webserver makes the same problems after a time. We restart the App when memory consumption is getting to high in a second instance and killing the old instance after getting secure that nobody is logged in. That behavior was always there in the 2019 and 2018 and still in 2020.
Thank you for that contribution. I guess, we just stay with our current method to restart the instances after a while. Fortunately Kubernetes makes this task easy.
But as you say, @Thorsten_Stueker a nice solution would definitely looks different.
The problem here is, will it kill some task currently being done? Is there some risk of a task half done or data corruption because of an external forced kill/start cycle? My proposed workaround was to make something to end gracefully instances while rising new ones when the current one has been run for some time and now it is idle, no harm will rise, no session will be broken.
Does someone know what classes leak?
Like if we know there is a structure leak and some objects are e.g. added to dictionary, but never removed, we may be able to find the dictionary in a timer regularly, look for old entries and remove those.
The real issue is, that we need to have more memory in the cluster than we usually would need. This is just a thing of prices. Strait calculated, the bug costs us about 200 EUR per month. Because, if the cluster runs out of memory, it starts killing and restarting pods (instances), which also might affect the end-user. So we have more memory available, to let it grow over day, until we can savely remove the blown pods.
A good working solution. But it would be better if we didn’t have to do it.
Maybe Greg can tell us about the leaks.
And maybe we can find a way to prevent them or cleanup.
It would be interesting to dump the list of objects in memory and see what keeps increasing. e.g. loop with runtime iterator and then count by class name what objects are in use.
As said, I suspect there may be a circular reference to find and release or objects accumulate references via global dictionaries/arrays.
Lars, the “hello world” app doing nothing leaks memory over time yes?
How fast does it grow / leaks? How frequent do you have to restart?
Maybe there are internal problem in Xojo that we didnt know about, but
i didnt see any noticeable memory leak for some of our web apps (Web 1.0 and Web 2.0),
even for two IOT webservices collecting data from several sensor nodes ranging between 50 ms - few minutes continuously. Or maybe i have to monitor more closely .
I hope your problem gets fixed and your system operates optimally.
If someone can provide me an example project, which reproducibly leaks memory in Web 1 or Web 2, I would volunteer to take a look for leaks.
But it needs to quickly leak by doing something, so I can reproduce it and cause a lot of leaks.
You can just open an empty project and call the App.HandleURL by setting a url in your browser.
It will leak (in web2.0) about 0.01mb /15 sec or per call to handleURL.
it grow aproximately 4-6 MiB per hour. 100 Instances take then 400-600 MiB per hour, we have 48 GB memory in our Cluster, which also runs other software. Currently we restart every night.
.