I believe that I have figured out my issue while setting up the project on the new Linux Dev VM. I recently updated GraffitiSuite components and the Xojo release. (right there, I should have clued in, right?) My copyfiles script on Windows was updated to reflect the changes, but my copyfiles script for Linux was not updated. Running debug builds on Windows was obviously fine. But I was copying the wrong files for Linux.
So, I fixed the copyfiles script for Linux and redid the build. Stopped the service on the target server. Moved everything (that needs updating) with Filezilla as usual. Checked the permissions on the executable file on the Linux target - The executable flag and the permissions needed to be updated for the user and for the group, but that is not unusual. Restarted the service. Accessed the application with Chrome, Firefox, Brave and Edge from outside my LAN, to go through the firewall, reverse proxy etc.(one of these days, I will have to buy a Mac to test with Safari, too. But I have friends). It works like a charm. Situation resolved.
It is interesting that the application did not crash, just remained unresponsive. Nor was there anything that I could find in the logs, or by running the application from console. After searching for elaborate issues, it was just an oversight. Sometimes I can be so dumbā¦
@Louis_D - I donāt think weāre having the same issue.
I have removed all references to GS in my stripped down project and removed the copy files step which copies the GS āscriptsā folder into the built app, and I can still hang the app reliably in my stripped-down testing version.
Iām continuing to rip out functionality to really get to the most minimal build where I can still 100% freeze the debugger while running the web app. (and then Iāll create a case)
Again, because I feel like this detail is easily lost in trying to think about all the options, when I cause the debugging build of the app to become non-responsive, the Xojo debugger is also non responsive with neither the pause or stop buttonsIN THE IDEresponding to clicks.
So this feels to me (who 100% is not an engineer at Xojo so take this with a grain of salt) like the Web Framework has stopped responding (vs. my app).
If my app was blocking the IDE, Iād expect high cpu or ram usage, neither of which are the case. The RAM allocated is very low and the CPU use is < 1%.
Iāve made a as-slimmed-down-as-I-could version of the project where I can still demonstrate the issue and have shared it in a confidential case.
I will update this thread with whatever discoveries are made, be they my learnings on how to better handle a Web2 app, or if thereās a framework bug and the workaround(s) for it.
Appreciate everyoneās help and this great community.
Well, I hope heās able to sort it out. My demo just died again. Restarting the Xojo web app (not the server or the load balancer) corrected the issue. Nothing in the logs to suggest a cause. I feel like everything else has been ruled out at this point. At least itās not every 24 hours, like it was before.
Thatās not likely to be the reason. The app is deployed with Lifeboat which uses the default Xojo Web app configured value of 200. The only change between before it started happening and now is the version of Xojo used to build the application.
