My Web App is running on Debian 12 on a LightSail server, installed with Tim’s LifeBoat. My app is depending heavily on UrlConnection because almost all it does is communicate with other servers and show the outcome in a customer facing portal. I have subclassed UrlConnection and use it for async communications, so I use delegation with ‘WeakAddressOf’ a lot to handle loading data in the fields and listboxes upon ContentReceived.
Every now and then, and hard to reproduce (and only occuring on Linux!), the app crashes with the above mentioned error I found in the log. The numbers that are shown in the errordescription vary a little bit. In nginx log I find a more detailed description of the error:
The line you’ve found in the nginx logs is quite common. I’ve never found the cause of why the Xojo Web app refuses the connection, but I’ve also never seen it have an effect on a running app. I don’t honestly think it’s related to your CURL / URLConnection issue.
For debugging I will create a separate logfile to store the complete request before I execute it. Maybe a timing issue on my part prevents building up a correct URL in some cases.
So this happens even before there is a connection to the socket from the web app.
Malformed content, packet or something else but clearly not from the xojo-weba-app (receiver) side i don’t see why this could be a socket in the webframework causing this. That probably means there is an issue with libsoup2.4-1 (urlconnection on linux) or something?
Perhaps update the nginx or the main system (where the url connection is calling from) ?
I’m a reading that you create URLConnection instances from an WebApp to another web app ?
Yes the App communicates with another server through the UrlConnection instances. In this case it’s getting data from a Business Central (ERP) service. I also tested on Ubuntu, same result. I will try to make a project to reproduce the error and report the issue.
The App crashes indeed before there is a connection. Crashing seems completely at random. I can repeat the exact same HTTP request multiple times with succes, but at some random point it fails, throwing this error.
It looks like I managed to prevent this error. I think user interaction in my App could cause race conditions leading to too many concurrent http requests. I managed down the number of URLConnections needed and gave asynchronous requests more time to complete. It is running stable since without errors.
In your case, that assertion seems to be coming from the systemd service, not from the Web Application. I can’t know from the log if it’s throwing that message as a consequence of the web app quitting abruptly, due to the “Unexpected error 9 on netlink descriptor” issue that appears later.
Have you also updated your OS software packages recently? Are the DigitalOcean monitoring graphs looking fine or can you spot something related to the hardware that could be causing this? Any increase in traffic maybe?
Please report this kind of issues, so we can keep a track them and fix them
Something is terribly wrong on my DigitalOcean droplet so I decided to create a new one and configure the WebApp in the exact same way.
The WebApp on the new droplet isn’t restarting every 30 seconds but every 2-5 minutes now:
2024-11-18 11:06:16: Application is ready
2024-11-18 11:17:44: Unexpected error 9 on netlink descriptor 31.
2024-11-18 11:17:48: Application is ready
2024-11-18 11:18:48: Unexpected error 9 on netlink descriptor 15.
2024-11-18 11:18:52: Application is ready
2024-11-18 11:23:44: Unexpected error 9 on netlink descriptor 25.
2024-11-18 11:23:48: Application is ready
2024-11-18 11:24:11: Unexpected error 9 on netlink descriptor 12.
2024-11-18 11:24:15: Application is ready
Have you also updated your OS software packages recently?
No that I know of.
Are the DigitalOcean monitoring graphs looking fine or can you spot something related to the hardware that could be causing this? Any increase in traffic maybe?
Bandwidth graph is huge since I upsized the droplet.
Thanks a lot. Just to attempt to narrow the issue, are you using SSL through Xojo Web or is it Nginx dealing with it?
I’ve tried to prepare a sample project to force that issue to happen, without any luck, but I’ll prepare a change that tries to protect the web framework against that issue.
Jeremie says the error started when he used Lifeboat 201 and upsized a DO droplet.
Lifeboat 201 was not available November 04 when this topic started.
I think there was another Lifeboat version after 184?
I don’t know, I was using version198. I think latency caused a condition where my subclassed UrlConnection sometimes (one in 20 to 50 occasions) started to soon in the Shown event of a webpage. A simple thread.SleepCurrent of 250 milliseconds just before UrlConnection.Send did the trick for me. If I remove this I can replicate my issue again. As said this wasn’t an issue on a Windows Server.
.