Hi,
we see the behavior, that our Web-FW-1 Webapp consumes more and more memory over time, without actually any usage.
This alone is not really a problem, but we’re running about 100 instances of the same app on a server cluster, which simply runs out of memory over time.
I know, that this could be a memory leak as often described here in the forum. But that the instances without any user over the last days also consumes more and more memory is strange.
What could be possible reasons?
Thanks!
We’ve seen the same in Web 2.0 there is a feedback case for this.
Perhaps it’s the same underlaying thing? You could try a simple empty Web1.0 project and see if that grows too. In web 2.0 the memory usage climbs slowly about 0.01 mb / 15 sec
Interesting. It is the same thing with just a simple “hello-world” application.
So it’s internal… in Web1.0 and Web2.0 then… pretty major i’d say.
Here is the case for Web2.0
<https://xojo.com/issue/63378>
thats a shame.
they stopped to fix thing in WebFW 1…
I guess thats one of the things we’re nor sticking with forever.
Currently we just restart the instances every night. But this is a hack . If I tell this to someone using other languages, they’ll start laughing…
Actually @Geoff_Perlman post said that they would fix issues. Forget what the sp ecific wording was (on phone atm).
This is fundamental I’d say. I have invested a lot in a web 1.0 project and plan similarly on running many instances. Surprised nobody raised it before against web 1.0.
@Greg_O_Lone have you come across this before in web 1.0 ?
Steve
I would appreciate that they fix several thing in the old web framework.
But I am pretty sure that Geoff only said, that they would fix absolut showstoppers, like if a browser won’t run your application anymore or 2019R3.2 doesn’t run on newer OS versions.
They are not investing in bugfixing. For web 2, this Issue could be addressed someday, but to do this with web 1, they have to release a new 2019-Version (2019 R3.3 probably) and I asume, this is not going to happen.
Yes that sounds familiar Lars.
Like I said I’m surprised since Web 1.0 was born that this didn’t come up and get fixed previously.
We found and fixed several memory leaks in the Web 1.0 framework over the years, but there were one or two that came down to fundamental design flaws which couldn’t be remedied without a complete rewrite. Those were fixed when we updated the framework to Web 2.0.
We did fix an issue recently in web 2 where HandleURL calls were spinning up sessions in the background which would automatically be purged when the default timeout occurred. This bug also existed in web 1, but it’s only a temporary memory leak and would not cause what you are describing above.
My suggestion is to do what you are doing now, that is, decide on a weekly maintenance window and restart the app using a cron job.
FWIW, regarding this:
It’s unlikely that we would release a new version of Web 1.0 for this. Browser technology moves forward at such a blindingly fast pace that we’d be stuck doing bug fixes forever.
Thanks @Greg_O_Lone for the transparent response. Regarding the above, out of interest is it just HandleURL or this one and HandleSpecialURL ?
How comes this together with that statement:
I also have a scheduled job to restart web application instances at 4:30 every day. My users span 3 time zones. this is the least disruptive moment to restart.
Sure, we also do this. But is that really a solution or more like a workaround?
It would affect both in web 1.
Also it’s very dirty - do you even warn users that the app is going down or just ‘surprise them’ ?
We run our application in a Kubernetes Cluster. The instance wouldn’t shut down until the last session is closed. Parallel the new instance is created and new Sessions are already directed to the new instance. With this, we have zero downtime.
But: if a user is very sticky and keeps its session alive, it takes time until old and memory-blown-up instances get killed.
In other words: we do our best, that the customer doesn’t notice, that there are serious issues in the background.
If it’s something in the JavaScript framework then yes, we may be able to provide a patch. But if the problem is in the back end code it’s unlikely that we would do another build of 2019r3.x
Oh guys. You constantly make me cry. It happens so fast, that a new MacOS, for instance, breaks old IDE-Versions.
This doesn’t sounds like “Yes, We Still Support Your Web 1.0 Projects”, as @Geoff_Perlman promised.
And the web fw 2 is still far away from the web 1 abilities in much cases…
It is what it is.
Also it’s very dirty - do you even warn users that the app is going down or just ‘surprise them’ ?
Very good point! I could not do this if my applications were aimed to the public at large. But my applications are aimed towards a defined group and procedures and guidelines expressly indicate that this is going to be done. A corporate environment does allow some flexibility that is not available with consumer applications.
We also just provide a b2b solution. But we care about how our customers use our software. For me, providing a zero-outage-service, has to be industry standard in 2021. And I expected, that the tools we use, help us with this. But nevermind, that are just seemingly to high expectations.