Xojo Web App Just Freezes (no errors, no crashses)

@Anthony_G_Cyphers - over in the thread: WebApp good in IDE bad in Deployment, you wrote:

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?

1 Like

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.

2 Likes

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.

Anthony

3 Likes

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.

the only way to deal with this is to look at the debugger console of the browser, all messages here are important.

Is there a public issue for that? Can we please have the issue # ?

Anthony mentioned in the other thread (Web Application Idle/Non Responsive - #28 by Anthony_G_Cyphers) that the case is private.
I will post the contents of my browser console here next time I run into 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

Are you using MySQL?

Yes mysql and MSSql at same time

This may be relevant, then.

2 Likes

ok since the issue is not public..
does anyone know if the problem exists with previous versions of XOJO 2024R4.2?

or if recompiling with xojo2024R3.1 or previous versions solves the problem?

According to this post in another thread, yes, compiling with 2024r3 helps:

Web app constantly restarting throughout the day by itself - #12 by Ryan_Hartz?

can you try and see if that helps? if not, maybe there is another problem.

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?

1 Like

Hi @Jeremie_L,

There is not a public issue for this.

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.

In my private issue, @Ricardo_Cruz said:

“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


  1. 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. ↩︎

Does it happen when you do transactions with tables that have string / var char as one of the columns datatype?

In my case no

What were you trying to accomplish with this?

@Greg_O - Nothing.

That was just cruft in a very old subclass (circa 2018) of Database.

I didn’t realize those connect calls were still there until I was auditing/editing a copy of the code for the example project for my case submission.

Anthony

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.

8 Likes