every now and then, like about every 1 to 2 weeks, my browser acts as it can’t connect or gets no response to a connection. if i clear cookies (which also clears some other stuff) and try again, then i can get in, though i have to login, again. i’m not seeing this happen anywhere else. i do have a few browser separate processes running concurrently. anyone else seen this happen?
browser: Firefox 82.0
os: Xubuntu 18.04.5 last upgraded 2 days ago
vpn: OpenVPN over private VPC running Ubuntu 16.04 LTS server edition (includes IPv6)
i lease a VPC at TransIP in Netherlands. i run an older Ubuntu on it. i set up my own VPN with OpenVPN on each end to get IPv6 and have my IPv4 appear from a different country.
logging in today saw a new problem. only partial content was delivered. this is what it looked like (1920x1080 image). i reloaded and got a full page. must be some packet loss somewhere. maybe there’s an IPv6 issue somewhere. i could be getting IPv6 connection attempts since my Firefox is set to favor IPv6. i will set up some tcpdumps to watch it for a while now that i see it is hosted at Hurricane Electric (a very good place to host serious servers).
any kind of network loss could cause a connection to fail to be established or delayed until recovery. any separate connection faces the traffic of the main connection and all the others. some images came in but that’s just more in the traffic burst. similar effects can just be the order of things in the HTML against the network burst demand.
i do, sometimes, get a “connect no response” from Google’s Gmail service. it will be several (4 to 8) in a row when it happens, then i’ll go a few days without that. i’m guessing it’s an internal failure, such as accessing a database cluster or load balancing issues. i kill the browser and retry rather fast so that might be the issue with them. when i want to check my mail, i want it “now”.
I wonder if your preferences for Discourse are causing extra load?
It looks like it is serving the CSS but having problems delivering the content within the timeout limits specified.
(BTW, have you set the Interface preferences to largest text?)
My guess is that you are using different settings that the rest of us and, since those settings are causing the server to take longer to collate dynamic content for delivery, you get timeouts that we won’t see.
I do not see a Reset to Default in the Discourse site prefs.
Also, most of the time, I use the Discourse App rather that the webbrowser to retrieve content. That SEEMS to include some of the interface overhead. But I think it mostly organizes monitoring of the topic updates in the 3 discourse powered sites that I visit.
Xubuntu 18.04.5 LTS bionic last upgraded 2020-11-01 and 5.1.3 although i don’t know how the Gramps version impacts the browser accessing the web site. the browser is Firefox 82.0.
Actually, I mention that you hadn’t specified those in your profile because they are usually the FIRST preferences change. (The forum automation actively presents those and suggests that you customize.)
If people haven’t customized the profile, they usually haven’t dug into the other, more obscure, preferences. The more deeply you change preferences, the more likely you are to run across something that is less-tested.
i don’t know anything about preferences. the buttons on the upper-right don’t show a gear icon (the usual for settings and preferences in a GUI or web site).
May it be that you have Noscript or any other .js scriptblocker installed as an extention/add-in for your browser and that this site has been added to a block list in one of those?
The problem with that idea (and my suggestion of a preferences problem) is that his issue is intermittent. And that it is infrequent.
Maybe there is a high load fallback setting in the configuration?
Although from the screenshot, the failure is in not showing the header text of the threads. And that could be either not populating, or, setting the text typeface color to white instead of black.
The first is the server not delivering from the database, the 2nd is a potential CSS error.
My worry would be that the Discourse database might be teetering on the edge of acceptable Query response performance. Most of the time it delivers within the timeout limits. But sometimes (maybe when burdened by simultaneous extra users) it misses that window.
Am I correct in recalling the first private trial of the forum were in Sep 2019? Maybe the database needs periodic maintenance? Maybe a database pack & re-index? Maybe a server reboot?