Web service: Need help understanding something

I have been working on my first web service app. The app is on Xojo Cloud, and I am using a desktop app to communicate with it. Following the example project and docs. Xojo 2023 R3

Things seem to have been working well. However, I encountered a problem, and this might just be me not fully understanding this concept

I made a test desktop app which does simple Add, Delete, and Retrieve Single calls to the web app. I deployed the web service app to Xojo Cloud, and the test desktop app worked. This was all done yesterday

Today I came in and wanted to test the desktop app again. Nothing was changed in this app. Just opened and ran and tested the calls. I received the following error

jsonexception lexicon error invalid char in json text

Ok, I thought maybe I just need to pull up the web service app in the browser. Tried the same test app, and received the error message again. Then I thought, what if I deploy the web service app to Xojo Cloud again and see what happens. This time, the test desktop app worked. Why??

Help me understand web services. Shouldn’t I just need to deploy the app one time, and the desktop app will make the call, the web service app connects to the db hosted on XC, and all is well and good? Why did this not work until AFTER I re-deployed the web app?

Here is the message in the crash in Xojo (not sure if it helps, but more info is better than less) :

<html><head><title>500 - Internal Server Error</title></head><body style="padding:20px"><h1>500 - Internal Server Error</h1><p>The server encountered an unexpected condition that prevented it from fulfilling the request.</p></body></html>

I looked up the 500 Internal Server Error, and it says there is a problem with the server itself. If this is the case, how is this corrected?

I mean, that’s the goal right? Errors can happen, but I don’t have access to XC logs so I can’t provide more information for you, sorry.

Re-deploying your app is like turning it off and on again. You gave it a restart and it worked. FWIW, I believe there’s a switch to do this from the web control panel for your Xojo Cloud account.

Internal Server Error 500 generally means that your Xojo Web app has crashed. It’s not usually a RuntimeException because UnhandledException is currently broken and doesn’t actually terminate the app :upside_down_face:

Turn it off and on again is my only recommendation for Xojo Cloud.

If you would like more control over your systems (or hands on support from me :slight_smile:) you can check out my app Lifeboat which will let you deploy your web app to your own Linux server.

I started using Lifeboat 2/3 weeks ago and I really recommend it.
While Xojo Cloud is nice and easy (click to deploy), Lifeboat is much more powerful and only takes 3-4 clicks to deploy.

My Xojo Cloud instance couldn’t handle the access load (20000 sessions per day).
It is now working much better on a Digital Ocean 4vCPU instance.

6 Likes

This. I was managing everything myself on some VPS. I’ve moved two servers over to Lifeboat (including the GraffitiSuite demo) and I couldn’t be happier.

2 Likes

I appreciate the responses fellas but am not quite looking for an alternate product…yet. Looking for how to get this to work properly without having to deploy everyday. Is this something that’s actually broken in Xojo?

I have given you everything I know, honest. Without server logs or your projects source code, there’s nothing more I can offer. Error code 500 means something bad happened on the server. Xojo Cloud uses a different reverse proxy technology, so I can’t even speculate.

UnhandledExceptin is malfunctioning by not exiting. I have tested and confirmed this with 2023r3.1. But with the software I use (nginx) a missing upstream would give you a 502 Bad Gateway.

I do my best to help, even with Xojo Cloud users, but it’s a little bit of a black box making it hard to offer external support for error resolution. You could contact hello@xojo.com for one on one support with them; but they hardly ever visit the forums without provocation.

I think I found the server error logs. Not sure if this helps. I am seeing a lot of “failed to make connection to backend” and “connection refused”

[Thu Dec 07 14:51:59.094837 2023] [proxy:error] [pid 28310] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:60244 (127.0.0.1) failed
[Thu Dec 07 14:51:59.094939 2023] [proxy:error] [pid 28310] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:51:59.094947 2023] [proxy_http:error] [pid 28310] [client 159.223.176.93:47682] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:51:59.095116 2023] [proxy:error] [pid 28310] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:63442 (127.0.0.1) failed
[Thu Dec 07 14:51:59.095128 2023] [proxy:error] [pid 28310] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:51:59.095131 2023] [proxy_http:error] [pid 28310] [client 159.223.176.93:47682] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:51:59.357491 2023] [proxy:error] [pid 2417] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:63442 (127.0.0.1) failed
[Thu Dec 07 14:51:59.357570 2023] [proxy:error] [pid 2417] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:51:59.357583 2023] [proxy_http:error] [pid 2417] [client 159.223.176.93:47688] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:51:59.357714 2023] [proxy:error] [pid 2417] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:60244 (127.0.0.1) failed
[Thu Dec 07 14:51:59.357729 2023] [proxy:error] [pid 2417] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:51:59.357734 2023] [proxy_http:error] [pid 2417] [client 159.223.176.93:47688] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:52:00.090778 2023] [proxy:error] [pid 777] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:60244 (127.0.0.1) failed
[Thu Dec 07 14:52:00.090884 2023] [proxy:error] [pid 777] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:52:00.090903 2023] [proxy_http:error] [pid 777] [client 159.223.176.93:47700] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:52:00.091061 2023] [proxy:error] [pid 777] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:63442 (127.0.0.1) failed
[Thu Dec 07 14:52:00.091074 2023] [proxy:error] [pid 777] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:52:00.091077 2023] [proxy_http:error] [pid 777] [client 159.223.176.93:47700] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:52:00.360698 2023] [proxy:error] [pid 23365] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:63442 (127.0.0.1) failed
[Thu Dec 07 14:52:00.360767 2023] [proxy:error] [pid 23365] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:52:00.360776 2023] [proxy_http:error] [pid 23365] [client 159.223.176.93:47706] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:52:00.360872 2023] [proxy:error] [pid 23365] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:60244 (127.0.0.1) failed
[Thu Dec 07 14:52:00.360883 2023] [proxy:error] [pid 23365] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:52:00.360888 2023] [proxy_http:error] [pid 23365] [client 159.223.176.93:47706] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:52:01.239136 2023] [proxy:error] [pid 1354] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:61416 (127.0.0.1) failed
[Thu Dec 07 14:52:01.239211 2023] [proxy:error] [pid 1354] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:52:01.239231 2023] [proxy_http:error] [pid 1354] [client 159.223.176.93:47714] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:52:01.239374 2023] [proxy:error] [pid 1354] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:60265 (127.0.0.1) failed
[Thu Dec 07 14:52:01.239398 2023] [proxy:error] [pid 1354] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:52:01.239401 2023] [proxy_http:error] [pid 1354] [client 159.223.176.93:47714] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:52:01.630227 2023] [proxy:error] [pid 1358] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:60265 (127.0.0.1) failed
[Thu Dec 07 14:52:01.630300 2023] [proxy:error] [pid 1358] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:52:01.630308 2023] [proxy_http:error] [pid 1358] [client 159.223.176.93:47720] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
[Thu Dec 07 14:52:01.630447 2023] [proxy:error] [pid 1358] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:61416 (127.0.0.1) failed
[Thu Dec 07 14:52:01.630463 2023] [proxy:error] [pid 1358] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Thu Dec 07 14:52:01.630468 2023] [proxy_http:error] [pid 1358] [client 159.223.176.93:47720] AH01114: HTTP: failed to make connection to backend: 127.0.0.1

Here is one of the calls from the desktop app:

try
  Var jCode As New JSONItem
  jCode.Value("RegCodes") = txtCode.Text
  
  XMEConnector.SetRequestContent(jCode.ToString, "application/json")
  XMEConnector.AllowCertificateValidation = False
  Var content As String = XMEConnector.SendSync("POST", "https://XCMiddleEarth.xojocloud.net/DeleteRegCode")
  
  content = content.DefineEncoding(Encodings.UTF8)
  
  Var json As New JSONItem(content)
  
  If json.HasName("DeleteRegCode") Then
    Var jCodeData As JSONItem = json.Value("DeleteRegCode")
    
    if jCodeData.Value("Deleted") = "yes" then
      ResultsArea.AddText("code deleted" + EndOfLine)
    else
      ResultsArea.AddText("This code was not DELETED")
    End If
  End If
catch e as NetworkException
  ResultsArea.AddText("NOT CONNECTED" + EndOfLine + e.Message)
  Return
end try

And here is the method in the web service app:

dim json As New JSONItem(jsonData)

dim theCode As String = json.Value("RegCodes")

dim sql as String = "DELETE FROM registerCodesTEST WHERE RegCodes = ?"
mDbRegister.ExecuteSQL(sql, theCode)

'if passes successfully, desktop app will see Added as yes and will delete from temp table
dim jsonCode As New JSONItem
jsonCode.Value("Deleted") = "yes"


dim jsonResults As New JSONItem
jsonResults.Value("DeleteRegCode") = jsonCode

Return jsonResults

On the web service app’s opening, the database is connected, and the HandleURL has the appropriate Select Case for the method when called. The desktop app is working now, but I feel it is because I deployed the web app earlier today. I will try it again tomorrow and see what happens. This morning before deploying the web app, the desktop one failed with the jsonexception error in the OP

Of note too. When I open the web app project, the server always shows as None. I always have to select the drop down box, click Refresh, and then choose my server name. Is this normal?

You’re probably going to want to contact Xojo Cloud. I don’t see anything jumping out at me as problematic with your HandleURL code.

What database are you using? Some have a timeout, so your code may be crashing trying to access mDbRegister.

Thanks for taking a look. Happy that looks ok at least. I will reach out to them in the morning

It’s XC’s supplied MariaDB. I’m not sure if that’s it though. The desktop app doesn’t crash after I deploy the web app. It happened this morning, but after deploying the web app, the desktop one ran just fine. I’ve noticed this in past days but thought nothing of it as I was just playing around trying to learn the REST model and chalked it up to inexperience. Yesterday I spent more time focusing on it and followed the example project and docs more closely and got it to work. Plus, the crash was in about 1-2 seconds. I’m assuming you are referring to the desktop caller app crashing and not the web app. Though, if you meant the web app, I would think that should’ve been ok since this morning was a new day, and the database is initiated on app.opening. Could cookies be a problem? Could the last test call yesterday stored a cookie that the db file was open, and then it timed out because the cookie was still present? Apologies for the probably simplistic questions. This is a brand new area for me

Yes, I mean the web app.

I think the database connection times out after 4 hours of inactivity. If you connect on app.open and then leave the web app running over night, that would explain why it crashed this morning, but started working when you redeployed the app - it would have made a fresh connection when the newly deployed app started.

One thing to try would be to have a timer access the database every hour or so. That might keep the db connection alive.

Huh, this is good to know. So before I shut down tonight, I added my CheckConnection method I use in my web app (regular one, not this web service one) to right before the HandleURL calls curious if that could’ve been it. I’ll see tomorrow morning if that was the thing I needed. Fingers crossed

This morning I tested the app again, and it gave me the JSONException error again. I might not have deployed the web service app last night with the additional CheckConnection calls, so I will have to wait a few more hours to see if anything is different later today (I did deploy this morning after my test, where the test app did work following deployment)

I checked the error log today and found this (shortened for space as the last 3 timestamp errors seem to just repeat)

[Fri Dec 08 05:36:47.320073 2023] [proxy:warn] [pid 2969] [client 193.106.29.122:62407] AH01092: no HTTP 0.9 request (with no host line) on incoming request and preserve host set forcing hostname to be XCMiddleEarth.xojocloud.net for uri /
[Fri Dec 08 14:00:55.572926 2023] [proxy:error] [pid 31687] (111)Connection refused: AH00957: HTTP: attempt to connect to 127.0.0.1:63460 (127.0.0.1) failed
[Fri Dec 08 14:00:55.572988 2023] [proxy:error] [pid 31687] AH00959: ap_proxy_connect_backend disabling worker for (127.0.0.1) for 60s
[Fri Dec 08 14:00:55.573005 2023] [proxy_http:error] [pid 31687] [client 159.223.176.93:39696] AH01114: HTTP: failed to make connection to backend: 127.0.0.1

One new error I did not notice from yesterday’s post was the first line, which is timestamped about 9 hours prior to my test this morning, which would be around 12am eastern time, if my math is correct. Does that error line mean anything to you? It’s a proxy warning, where the others are proxy errors

I did just send a message to Cloud Support, so hopefully they can chime in. But posting in here in case you web service gurus can make any sense of this and offer suggestions

The app at port 63460 seems dead.

People experiment crashes over time due to memory leaks and/or Nil Object Exceptions, so, many have “app reboots” set over the night. Maybe you should monitor your memory use over time.

Something to keep in mind… Xojo Cloud runs apps as a service which will automatically restart the app if it crashes. I’d bet that what’s actually going on here is that your app is either hanging, getting caught in a tight loop making it impossible for it to respond or that you’re experiencing a denial-of-service attack where the server is simply overloaded.

Would this be done in the Build Settings section? App stats, or named something like that? I peeked at that this morning or yesterday, and all the percents were low to zero. Maybe I need to check it more often, if that’s where I would monitor it

Could a server timer do this? And is there a Quit to close the app for web like there is on desktop? Or is there something different to accomplish quitting and rebooting?

Would I not experience the error throughout the day if this were the case? After this morning’s fail, I redeployed the web app and tested the desktop caller several times over the course of about 8 hours, and it ran fine. To my knowledge, the call to the web app is very simple. In this one, there are no loops. It’s a straight call to delete an item with a response back as to if the item was deleted or not

The test app is reaching the same database (different table) as another standard web app I have (non web service app). Not sure if that matters having more than one app talking with the same db. The number of users of the web app is very low, only about 50 sessions per day (just recently launched it, so not many users at this point)

https://documentation.xojo.com/api/language/runtime.html

Inspect MemoryUsed for unusual high values

Many possibilities, one based on Greg’s:

Could be:

If IsTimetoSayGoodBye Then
  // force the service restart on abnormal termination
  Raise New RuntimeException("Terminated for reload", 1) // Maybe the system logs the reason
  Quit(1) // It could do it too more silently
End

Very symptomatic of something accumulative as memory leaks. Depending on where the problem rises in the code it may not crash, it may cause an unexpected exception at some point that gets caught (do not crash the app) and the app gets unstable.

If at end it is not your case, your code may have some special condition able to freeze it. It will be a detective work to find it out… :smiley:

Thanks for the info Rick! I will do some memory checks to see if it gets too high

Say I were to use that sample code you provided, and were to use it in a timer, the best place to do this would be on the app level and not a timer dragged on the window, right? I assume the window one would never really get called since the window doesn’t display on a web service app?

One thing I do like with coding is playing detective, especially when I can solve the case

You are correct.
The timer needs to be at the app level.