Both my deployed apps and my database management took (Navicat) cannot connect to either the MySQL or PgSQL databases on my Xojo Cloud account. From the apps I get a “Database connection failed” message and from Navicat I get “server closed the connection unexpetedly” message.
I have tried using the Restart button on the Xojo Cloud Control Panel to no avail. I am not sure it is working since a copy of XCtop running on my account shows an uptime of 21 days.
What to do?
I’ll be able to look at this shortly.
I’ve restarted your MySQL instance. Lets see if that helps.
All the apps using MySQL work now. 1/2 the apps using PgSQL will load but not connect to the database the other half give a “Mutex cleaned, application could not launch.” error instead of launching. Previously using the Restart button on the Xojo Cloud Control Panel would fix the mutex error but not now.
Are you sure the restart button is working? XCtop now says the server has been up for 22 days. I assume that if it really restarted that value would be much less.
I’ve restarted the PostgreSQL instance on your server.
FWIW, We don’t recommend running both MySQL and PostgreSQL on a 1GB server at the same time because it will sometimes cause services to be shut off when memory gets low.
I’ll check with the VPS provider. It may be that your server is in a state where it cannot be restarted for some reason.
Edit: I don’t see any reason why your server wouldn’t restart. If this continues to be a problem, please let me know a good time that we can test this ourselves when you wouldn’t mind your server getting restarted.
I’d prefer to use one DB or the other but time constraints and instability in the DB connections caused me to end up with two. I think I have found the problem but since we are still in the middle of tax season I have left well enough alone. Until this latest problem everything has been very stable. Only the current year lookup in one county had crashed twice with the mutex error and a restart fixed that. I’m fairly sure that crash is related to umlauts.
I still have 1/2 of the apps that use PgSQL not working and returning the mutex error. Since these are business apps restarts on the weekend are no problem, they just need to be working by Monday. So restart anything on my account at will!
If you restart a VPS shouldn’t top uptime reflect that restart?
Where are you using umlauts?
I would expect so, but I really need to check on it.
One thing that has worked for other users in the past is just redeploying the app.
Umlauts came in data we were provided. Apparently they cause crashes, especially when using MySQL.
Why would these apps work for months with almost no problem and then go nuts yesterday? Did something change?
[quote=313815:@Lewis Gardner]Umlauts came in data we were provided. Apparently they cause crashes, especially when using MySQL.
Why would these apps work for months with almost no problem and then go nuts yesterday? Did something change?[/quote]
Are we talking application crashes or uncaught exceptions?
When I first came across umlauts they caused horrific crashes in the IDE. The app would just crash with no error or traceable information. It took a while to zero in on records that were causing the problem since the little dots were almost invisible. I finally saw them by reviewing hex of text near records that caused the crash. It’s been awhile but I believe I was told that the problem was in the database plugin and not something Xojo had control over.
The apps I have deployed come in two basic flavors, current and historic. The current data is refreshed every day and appended to the historic each year. Since there was much more interest in the current data I started with that using PgSQL and all appeared fine. I got the current data apps deployed and started working on the historic apps. As I moved along I was convinced that MySQL was a better choice by some wizbangs and complex queries did seem easier so I started using that. Then I discovered the umlaut issue. Since the historic data is static I cleaned the umlauts and stuck with MySQL. The current data ended up staying in PgSQL. However I think there may still be an umlaut issue since the data that contains those is the one that has stopped with the mutex error three times now.
In any case the restarts you did and re-uploading the apps with the mutex errors now has everything working. I must say I appreciate the much faster uploads in 2016r4.1! I wasn’t looking forward to over a hour of mindless baybsitting. I was done in less than 10 minutes! Well done!
I wonder if your MySQL problem is one of encoding than anything else. When you pull data from the database, are you defining the encoding as UTF8?
I have assumed it was an encoding issue but since the only verifiable error I found was with umlauts it stuck to calling it that.
I don’t know how to “define the encoding as UTF-8”. Perusing developer.xojo.com I found this bit-o-code; teams.Append(DefineEncoding(teamName, Encodings.UTF8).ToText)
Which may work. I can’t remember if the crash happened before I got a record set or when I was filling in a WebListBox . If it is the latter how what would be the best way to implement when using code like the following?
while not rs.eof
lstSearchResults.addRow rs.idxField(1).stringValue, rs.idxField(2).stringValue, rs.idxField(3).stringValue
Or is there a way to convert UTF-8 -> ToText more cleanly than on each individual field?
Since they are strings, you could create an extension method like this:
Function UTF8(extends str as string) as string
If str.encoding = nil then
Return DefineEncoding(str, encodings.UTF8)
Return ConvertEncoding(str, encodings.UTF8)
And then just append the method to the end of a he stringvalue calls like this:
Thanks! I’ll give it a try!
I’m still having Xojo Cloud proiblems.
More apps throwing mutex errors. I need to get this restart thing cleared up. I checked with a friend that works on VPSs all day and he assures me that uptime as reflected in top should zero when a VPS is restarted. I’m fairly sure that is what happened before when a restart was done.
Are you guys SURE that the Restart button on the Xojo Cloud Control Panel actually restarts the server? That button not working would explain a lot. Having to redeploy to restart an app is not the easiest fix…
I’ve not had an issue in while with an App restart clearing a mutex error. I used to get them a lot but not recently.
My experience is that mutex errors occur for a couple of reasons. None of them confirmed, in any way, but they tend to happen more for these reasons:
I’m deploying a new version and have the old version still running in the browser.
The app quits unexpectedly. Something happens that it aborts in such a way that the app can’t recover. Plugin issues are good ones for this. Error logging may, or may not help trying to solve this one.
Not a lot of help, I know, and YMMV, but I’ve not had too many issues recently.
I’ll certainly keep item one in mind!
I’m fairly sure number two is what is happening to me. Part of my problem is with 20 web applications deployed just checking becomes a bit of an issue. Add in that with web applications, unlike desktop, I may not hear about a problem for quite some time. Maybe I should build something to keep an eye on things…
Ok, so we found an issue with our server restart mechanism. We have updated the Xojo Cloud component responsible for system restarts and it will be available to you in the next 20 minutes.
[quote=314156:@Lewis Gardner]I’ll certainly keep item one in mind!
I’m fairly sure number two is what is happening to me. Part of my problem is with 20 web applications deployed just checking becomes a bit of an issue. Add in that with web applications, unlike desktop, I may not hear about a problem for quite some time. Maybe I should build something to keep an eye on things…[/quote]
As I mentioned before, my suspicion is that your Xojo Cloud server is running out of RAM and your apps are actually crashing. When this happens the mutex files don’t get properly deleted. The fact that you are trying to run MySQL, PostgreSQL and 20 apps on a 1GB server is probably a big part of the issue here. You may want to consider upgrading to a larger server to handle all of this load.