My only remotely similar experience recently was with the GraffitiSuite Demo freezing around 24 hours after deployment when built with 2024r4.x and 2025r1.x. And, of course, the service appeared to be running to the system so it would just hang in that dead state rather than being restarted.
I still don’t know what was causing it or what fixed it, but it’s been solid for a few days now after setting up other locations with the same build to see if it was just the one VPS acting up.
I’m having this exact same issue (the web app does use Graffiti Suite but I’m not at all convinced this is causing the issue since, like you, it only has been occurring in Xojo 2024r4.x builds of the app)
You posted ~4 days ago. Did a new VPS “fix” things, or are you still seeing the same eventual hang/freeze of the Graffiti Suite Demo site?
I didn’t fire up a new VPS. It just sort of cleared up on its own after I spent massive amounts of time trying to find the cause, asked two others to put up test instances of the demo in their hosting spaces (including one in Xojo Cloud) which never exhibited the issue, and added a lot of additional logging.
Don’t know what caused it, but it’s ceased now. The only thing I can think of is that I accidentally slipped forward in the Xojo prerelease version I was using to try and reproduce the issue.
I don’t believe it was a GraffitiSuite issue as I never found any evidence to confirm that, and it ceased freezing using the same GraffitiSuite source code.
Just as an fyi, Xojo confirmed my issue; it’s related to MySQL databases.
I made some adjustments to my database code so my running web application is much less “aggressive” in the number of calls it makes to ‘MySQLCommunityServer.Connect’:
This has (so far!) greatly improved the stability of my app.
There is a confirmed issue(s) on the Xojo framework side of things, but things are still being analyzed by Xojo team so I don’t want to speculate until I hear more.
Just for the record, I am experiencing the same thing. Login to my web app, work for a little, go to another tab, come back after a while and see you clicks being ignored by the app. No MySQL involved (diehard Postgres advocate here). “Top” on the server (Ubuntu 20.04) doesn’t show anything special. Login in again and all is well. No idea what could be up there. The app throws some Javascript exceptions (caused possibly by the GraffitiSuite, not sure though), don’t think this could be it.
I also have a similar problem
The webapp freezes randomly and stops responding to connceted users and to new accesses and does not highlight errors even in the event app.UnhandledException
I added a log for each activity performed by users but even the logs do not highlight any specific event that triggers the application to freezes or crash
in fact the application stops responding but remains running and does not restart to respond until it is closed and reopened
to test I added to the app.handleurl event the management of a request (http://x.y.z.b:8080/closesessions) that closes all currently active sessions in order to close all users activities/sessions, this only works when the activity is not already freezed, but when webapp if freezed the event app.HandleURL also not responds
anyone have any suggestions
app compiled with xojo 2024R4.2 and 2025R1.1 on w10 pro
I think it’s the same issue I posted a while ago. Everything worked fine up until Xojo 2024r3, and from then on (even the latest 2025r1), it crashes on all of them.
At the time, I made the first post thinking it could be Lifeboat, then GraffitiSuite, since they were my only third-party tools and Xojo didn’t mention any errors.
Then I thought about MySQL, and to this day I still have the problem. I’ve had to do all my builds with 2024r3.
On most of my systems, the MySQL connection opens, closes, and closes; I don’t keep a session open on the database.
Everything worked up until 2024r3. I’ll leave some of the posts where we discussed these issues.
So now the problem is with Xojo, on MySQL. It would be logical. Is there any news on this?
Creo que es el mismo tema que publique hace bastante, hata Xojo 2024r3 todo bien a partir de ahi (incluso la ultima 2025r1) se tranca en todas.
En su momento el primer post lo hice pensando que podia ser lifeboat, luego graffitisuite, ya que eran mis unicas herramientas de tercero y Xojo no mencionaba ningun error.
Luego lo pense hacia el lado de MySQL y hasta la fecha sigo con el problema, he tenido que hacer todas mis compilaciones con 2024r3.
La mayoria de mis sistemas la conexion a Mysql se abre, se realiza y se cierra, no mantengo sesión abierta sobre la base.
Todo funcionaba hasta la 2024r3, dejo algunos de los post que habiamos comentado estos temas.
Asi que ahora el problema es de Xojo, sobre MySQL, seria lógico, hay novedades al respecto?
I was able to make a very trimmed down version of my main web product to demonstrate the issue, but the example still contains confidential code and can’t be in a public issue.
“We’ve also managed to reproduce the issue with a little stress project without having to turn on the Profiler.”
I don’t want to put work on anyone’s plate, but maybe Ricardo could share that project in a new, public issue with more details?
–
For everyone following this thread:
As mentioned above, my solution is to try and minimize the number of calls I make to ‘MySQLCommunityServer.Connect’ to the absolute minimum number of calls required.
I my app I maintain a “pool” of connections (an array of instances of MySQLCommunityServer objects) which is shared across all the active sessions. (this part not new and not the solution; I’ve done this for a long time)
Previously: I used to call ‘.Connect’ “every time I ran a query” [1]
Now: I only call each MySQLCommunityServer object’s ‘Connect’ method when I initially create it, and then never call ‘.Connect’ again on said object unless it reports a connection error.
Since I made this change, I haven’t had my main, very busy, production Web App get “stuck” in a non-responsive, limbo state. (knock on wood)
Anthony
In reality, it’s a little bit more nuanced/complicated than this since sometimes multiple queries were run in a single transaction, but in general, simple: SELECT name FROM customers
style queries were always calling ‘.Connect’. before they were ran. ↩︎
What we’ve seen is a possible race condition when using MySQL (Postgre and other backends are probably fine). The test was just several Thread instances using SelectSQL. Both Console and Web projects were affected.
William pushed some fixes to 2025r2, so everyone with access to the betas will be able to start testing it soon to see if it also fixes the issues in their projects.