With older Lifeboat and Xojo2024r3x, right?
Yes, correct.
1 Like
I see @IVAN_FERNANDEZ had a similar issue using 2024r1.1 as reported in this issue.
Anyway, I rebuilt the app using 2024r1.1 and it is working correctly for the past 20 minutes.
260 sessions were opened and no crash so far.
EDIT: actually, the web app just crashed again:
2024-11-19 15:02:58: Application is ready
2024-11-19 15:31:44: Unexpected error 9 on netlink descriptor 67.
@Jeremie_L did you test with my workaround?
Yes I tried the workaround and still have the issue.
ok, sorry it didn’t work out for you, hope that Ricardo’s fix will work. When released I will check if that also fixes my issue.
So I still have the issue with Xojo 2024r1.1 but it only happens every 2 or 3 hours.
I made the mistake of deploying my app with a newer version of Xojo and it was crashing every 30-60 seconds.
Can you privately share your app with Ricardo?
Having some code that crash so often could help him find the problem.
Yes I will share it with Ricardo.
But I think it is a difficult bug to track. My WebApp has 20.000 visitors per day at the moment. The issue wasn’t happening previously when I had much less visitors.
The peak will be in 20 days where I expect 50.000 visitors per day.
It might be a better idea to set up multiple servers running my app + a load balancer instead of running several instances of the app on the same server.
@Jeremie_L is there any correlation with concurrent users and crashes? Do you have a way to track this? (maybe that’s part of what you were trying to log…)
I’m curious if there’s a “magic” number (say >500 concurrent users) which causes things to break.
If so, it might be something in Xojo framework or something in how Linux is managing sockets (there’s an OS limit, perhaps a configurable one?)
I’m “thinking out loud” here after looking at articles like this one:
https://www.baeldung.com/linux/increase-max-tcp-ip-connections
I believe there is, yes. I see SessionCount growing in my logs and dropping all of a sudden:
Time SessionCount
2024-11-21 10:45:09 22
2024-11-21 10:45:09 17
2024-11-21 10:45:02 115
2024-11-21 10:44:57 114
2024-11-21 10:44:55 114
2024-11-21 10:44:55 114
When SessionCount is lower than 100 it doesn’t seem to crash.
Thank you very much for sharing that article.
I made some changes on the server to increase
sysctl net.core.netdev_max_backlog 1000 → 2000
and
sudo sysctl net.ipv4.tcp_max_syn_backlog 256 → 2048
2 Likes
Hi everyone, sorry I’ve been away. I have been unwell this week. I will be following up on this to see what, if anything, I can do from my side.
2 Likes
@Jeremie_L do you happen to monitor the memory usage ?
Yes I do, and it looks “normal”
Whenever the memory usage goes down abruptly, one instance of the app has crashed/restarted.
1 Like
I asked because the socket pool may have something to do with this (at least on some occasions this error on other programming languages seems to come when connect is called on an already connected socket) but that doesn’t mean that this is the case here.
My WebApps on the pi (using urlconnection also) do not seem to have this issue, though they do get lot less sessions
I strongly believe Lifeboat 201 wasn’t causing the issue and I am sorry about writing that in a previous post.
The crash happens very very frequently with Xojo 2024r3 and less frequently with 2024r1.1
I am still using Lifeboat 184 for this app because I am trying to rule out every possible source of problems.
I refactored my app today to use a direct MySQLCommunityServer connection instead of URLConnection to a php middle-ware running on another server.
Every WebSession that opens now only creates 2-3 URLConnections instead of 5-6 previously.
Unfortunately the app is still randomly crashing 
1 Like
Looks like i’m not using urlconnection on one of my web apps but it also never crashed.
It’s getting a pretty constant load of App.HandleURL requests, and presents webpages.
It’s running from Xojo 2024 R3.1 (pretty recent)
Debian 10 AMD64
So it may definitely be some kind of outogoing socket (like CURL or URLConnection or such).
So it seems I have fixed the issues I was facing with my WebApp.
Web App built with the latest version of Xojo.
I reverted to using two droplets: 2GB, 1vCPU, Debian 12.
Lifeboat configured the web app to only run one instance per droplet.
Using a DigitalOcean load balancer to route traffic to one droplet or the other, depending on the load.
I still have one small issue, it seems that sometimes the load balancer will route traffic from one Web Browser to Droplet 1. Then a few minutes later will route to Droplet 2.
This is supposed to be handled by a cookie but I do not see the cookie being set in the browser.
Seems it doesn’t work because I am using HTTPS Certificate Passthrough.
Is there something that needs to change so that Digital Ocean will handle the SSL certificate then?
I’m using Cloudflare as my NameServer for the domain and don’t want to change that.
So I can’t let DigitalOcean manage the DNS settings.
Workaround
I copied the SSL Certificate information created by Lifeboat/Letsencrypt on one of the Droplets into the DigitalOcean Load Balancer settings:
- cert.pem
- chain.pem
- privkey.pem
The DO-LB cookie is now correctly set.
I know this isn’t best practice because the certificate won’t be able to auto-renew.
But the certificate is valid until Feb. 2025 and I won’t be using the load balancer anymore in January 2025.
2 Likes