Refreshrefreshrefreshrefresh
-
-
@Scarlet_Manuka said in Refreshrefreshrefreshrefresh:
Can you (complainers in general, not @error) really not accept occasional downtime in the middle of the day?
The answer to that question is , because the updates do not cause downtime.
-
@Scarlet_Manuka said in Refreshrefreshrefreshrefresh:
@error said in Refreshrefreshrefreshrefresh:
You'd never pass as a USian.
Oh, how... regrettable.
-
@ben_lubar said in Refreshrefreshrefreshrefresh:
the updates do not cause downtime
That depends on your definition of downtime. It causes a "reload the page" toaster that cannot be dismissed and that takes up half the screen on mobile. This severely interferes with reading, and pretty much forces one to refresh now. The ensuing 30 seconds or so of jellypotato may not be much downtime, and the server may be up, but I'd still classify it as downtime for the individual user.
-
@HardwareGeek said in Refreshrefreshrefreshrefresh:
that cannot be dismissed
It can be dismissed by clicking on it (recommended) or by clicking the X in the upper right corner of the notification (not recommended).
-
@ben_lubar said in Refreshrefreshrefreshrefresh:
@Scarlet_Manuka said in Refreshrefreshrefreshrefresh:
Can you (complainers in general, not @error) really not accept occasional downtime in the middle of the day?
The answer to that question is , because the updates do not cause downtime.
That's actually irrelevant to what I was saying. Regardless of whether the downtime is due to updates or not—and I'm quite happy to believe that it's not—I don't think this forum should be such a vital part of anyone's day that it's necessary to complain every time it goes down, given that it's already been said that you're trying to find the cause.
Indeed, the fact that it's not associated with the updates makes it even more pointless to complain to you about it. Until the actual cause is found, complaining about it will achieve nothing (except to divert your attention from more useful activity).
-
@ben_lubar said in Refreshrefreshrefreshrefresh:
It can be dismissed by clicking on it
Mobile? That's different.
-
@Scarlet_Manuka said in Refreshrefreshrefreshrefresh:
Oh, how... regrettable.
We see that a lot from people in lesser countries. Aesop had a fable about it. The lesson was something about sour grapes.
-
@FrostCat said in Refreshrefreshrefreshrefresh:
The lesson was something about sour grapes.
That would only be applicable if I had, at some point in time, wanted to be an American.
-
@HardwareGeek said in Refreshrefreshrefreshrefresh:
@ben_lubar said in Refreshrefreshrefreshrefresh:
It can be dismissed by clicking on it
Mobile? That's different.
Have you asked Donald Trump if you can borrow his tiny fingers?
-
@ben_lubar said in Refreshrefreshrefreshrefresh:
You do realize the intentional restarts happen in a way that results in 0 downtime, right?
No. One. Cares. While it brings downtime and refreshes, we want it to be at most once a day at a known time.
Shut it with the stupid blame heavy, "You know, YOU could be helping me with the job I took by choice" we like you, but that's simply pathetic.
-
@blakeyrat lol.
Nope.
-
@FrostCat said in Refreshrefreshrefreshrefresh:
but it's actually BETTER than AT&T where I work
Well that's not that hard to pull off.
Now if it beats VZN, that's impressive :P
-
@ben_lubar I believe the users' complaint is not with server downtime but with client "downtime".
If the page doesn't actually need a reload, that toaster should be entirely removed. If it does need a reload, that counts as client downtime which they don't like...
-
@sloosecannon said in Refreshrefreshrefreshrefresh:
@ben_lubar I believe the users' complaint is not with server downtime but with client "downtime".
If the page doesn't actually need a reload, that toaster should be entirely removed. If it does need a reload, that counts as client downtime which they don't like...
But it's 0 downtime! Ben said so!
-
@error let's call it a "service interruption" then, it's not downtime but your service is damn well interrupted all the same.
-
@Arantor This site goes down more often than your mom!
-
@Arantor said in Refreshrefreshrefreshrefresh:
@error let's call it a "service interruption" then, it's not downtime but your service is damn well interrupted all the same.
Yeah.
I mean, if you want to be completely technically correct (the best kind!), it is zero downtime.
But it's still an interruption and an annoyance to the users of the site. If it can't be avoided, that sucks, but so be it, but if there's a way to avoid it (does it really need a refresh?), that would obviously be a better way to do it.
I also posted an "RFC" at the nodebb community site to see if anyone has any ideas on how to improve the resilience of the socket.io connections. If they're made more resilient, a refresh should almost never be required...
-
@sloosecannon said in Refreshrefreshrefreshrefresh:
@Arantor said in Refreshrefreshrefreshrefresh:
@error let's call it a "service interruption" then, it's not downtime but your service is damn well interrupted all the same.
Yeah.
I mean, if you want to be completely technically correct (the best kind!), it is zero downtime.
There's no such thing as zero downtime.
-
Can't it be changed so the next click to a new topic or whatever causes a refresh instead of spa navigation?
-
@Jaloopa said in Refreshrefreshrefreshrefresh:
Can't it be changed so the next click to a new topic or whatever causes a refresh instead of spa navigation?
Actually, that's a really good idea...
cc @julianlam, @TDWTF-NodeBB-Development - could that be implemented reasonably?
-
@sloosecannon I think did it that way, and only prompted for a restart if you'd been on the same page for ages
-
@sloosecannon said in Refreshrefreshrefreshrefresh:
could that be implemented reasonably?
probably, yeah.
if i remember this weekend i'll see if i can find where the hook is that would need that.
-
@kt_ said in Refreshrefreshrefreshrefresh:
Can we replace that error message with "Shit's broken yo"?
-
-
@Magus said in Refreshrefreshrefreshrefresh:
No. One. Cares. While it brings downtime and refreshes, we want it to be at most once a day at a known time.
You've already been told that you're wrong. The actual updates are pretty infrequent.
-
@boomzilla I don't care if you "tell me" I'm wrong. I'm not. If you do things that make me refresh, do it regularly and consistently.
And then there's the fact that whenever the updates occur, we all 502 2-3 times before it tells us to refresh. Seriously, just batch your daily updates. It can't be that hard to do at a regular time.
-
@Magus Ben L seems to think there's no link between the 502 and the updates, but I would have to disagree also.
-
@Magus said in Refreshrefreshrefreshrefresh:
I don't care if you "tell me" I'm wrong
Obviously.
@Magus said in Refreshrefreshrefreshrefresh:
I'm not.
:head_desk:
@Magus said in Refreshrefreshrefreshrefresh:
If you do things that make me refresh, do it regularly and consistently.
You are acting as brain damaged as blakey often does. Stop it.
@Magus said in Refreshrefreshrefreshrefresh:
Seriously, just batch your daily updates.
@blakeyrat said in Refreshrefreshrefreshrefresh:
Ben L seems to think there's no link between the 502 and the updates, but I would have to disagree also.
Yes, that's what most of them are about. They're restarts after nodebb gets hung up and stops responding and an admin kills / restarts them.
-
@boomzilla You're saying our forum crashes as often as had cootie storms?
-
@boomzilla Maybe the confusion is that the updates are fucking constant and the 502 errors are fucking constant and so it feels like a constant barrage of shit.
-
@boomzilla I'm talking about the ones that have an update log posted after the refresh. What, do updates just get added and only applied when the thing goes down anyway? Why can't you just tell us that instead of calling us idiots for observing how things look?
-
@JazzyJosh No. There are cootie storms where a node process is using 100% CPU. Sometimes they're short lived. If they aren't then eventually it gets noticed by an admin and the process is killed.
-
@JazzyJosh said in Refreshrefreshrefreshrefresh:
@boomzilla You're saying our forum crashes as often as had cootie storms?
Subjectively, I'm not sure it happens quite that often, but that does seem to be the gist of what he and Ben are saying.
Edit: Or maybe not;
-
@Magus said in Refreshrefreshrefreshrefresh:
Why can't you just tell us that instead of calling us idiots for observing how things look?
Bias.
-
@Magus said in Refreshrefreshrefreshrefresh:
Why can't you just tell us that instead of calling us idiots for observing how things look?
I told you what was going on. But you ignored it and then I called you an idiot or whatever.
-
@boomzilla no, you just said they were unrelated, and you still haven't confirmed or denied my summary. I get a 502, then a refresh notification then there's an update info posted. That's reality. Explain it.
-
@Magus When an update happens, we start a container running nodebb in the background. When that's up, the nginx switches talking to the new container instead of the old container. Then the old container is shut down.
I could possibly see that happening if you were in the middle of a request right at the point where the containers did the switch over. I don't know enough about how those sorts of things work on that level to say one way or the other.
When I restart the processes, I get the update toasters. Most of the update toasters I see are due to cootie activity, not restarts for upgrades. The only time I see a 502 page is when I try to load the site during a cootie storm.
-
@boomzilla said in Refreshrefreshrefreshrefresh:
@Magus When an update happens, we start a container running nodebb in the background. When that's up, the nginx switches talking to the new container instead of the old container. Then the old container is shut down.
I could possibly see that happening if you were in the middle of a request right at the point where the containers did the switch over. I don't know enough about how those sorts of things work on that level to say one way or the other.
When I restart the processes, I get the update toasters. Most of the update toasters I see are due to cootie activity, not restarts for upgrades. The only time I see a 502 page is when I try to load the site during a cootie storm.
NodeBB uses socket.io, which (by default) uses WebSockets. Basically it keeps an open connection to the server so it can receive push updates. If you point nginx at a new instance and take the old instance down, that WebSocket is still going to die (perhaps not gracefully). This could explain some of the "downtime" caused by these "0 downtime" updates.
-
@error If the WebSocket is disconnected, several features (notably the Submit and New Topic buttons) stop working with ZERO UI to indicate the problem. And there's no time-out or anything to find the error after-the-fact.
That's really the issue. Shitty UI. If it just greyed-out the controls in the few seconds it took to reconnect, it'd be a whole lot nicer. Not as good as a non-broken forum, but at least people would KNOW why their 6 paragraph post didn't send suddenly for no reason.
-
@blakeyrat said in Refreshrefreshrefreshrefresh:
If it just greyed-out the controls in the few seconds it took to reconnect, it'd be a whole lot nicer.
Agreed. Ben talks about a spinner that appears, which is like, the size of the search icon, right next to it, in the least noticeable spot possible. That doesn't cut it.
-
@accalia I went poking through nodebb.min.js (prettified).
Here's where it registers the event:
$(document.body).on('click', 'a', function (n) { if (this.target !== '' || this.protocol !== 'http:' && this.protocol !== 'https:') { return } var i = this.host === '' || this.host === window.location.host && this.protocol === window.location.protocol && (RELATIVE_PATH.length > 0 ? this.pathname.indexOf(RELATIVE_PATH) === 0 : true); if ($(this).attr('data-ajaxify') === 'false') { if (!i) { return } else { return n.preventDefault() } } if (i && $(this).attr('href').endsWith('.rss')) { return } if (e(this.href) || this.protocol === 'javascript:' || $(this).attr('href') === '#') { return n.preventDefault() } if (!n.ctrlKey && !n.shiftKey && !n.metaKey && n.which === 1) { if (i) { var o = this.href.replace(t + RELATIVE_PATH + '/', ''); if (window.location.pathname === this.pathname && this.hash.length) { window.location.hash = this.hash } else { if (ajaxify.go(o)) { n.preventDefault() } } } else if (window.location.pathname !== '/outgoing') { if (config.openOutgoingLinksInNewTab) { window.open(this.href, '_blank'); n.preventDefault() } else if (config.useOutgoingLinksPage) { ajaxify.go('outgoing?url=' + encodeURIComponent(this.href)); n.preventDefault() } } } }) }
Then
ajaxify.go
does the actual navigation, if it's supposed to be ajaxy:ajaxify.go = function (e, t, i) { if (!socket.connected) { if (ajaxify.reconnectAction) { $(window).off('action:reconnected', ajaxify.reconnectAction) } ajaxify.reconnectAction = function (n) { ajaxify.go(e, t, i); $(window).off(n) }; $(window).on('action:reconnected', ajaxify.reconnectAction) } if (ajaxify.handleRedirects(e)) { return true } app.leaveCurrentRoom(); $(window).off('scroll'); if ($('#content').hasClass('ajaxifying') && n) { n.abort() } if (!window.location.pathname.match(/\/(403|404)$/g)) { app.previousUrl = window.location.href } e = ajaxify.start(e); $('body').removeClass(ajaxify.data.bodyClass); $('#footer, #content').removeClass('hide').addClass('ajaxifying'); ajaxify.loadData(e, function (n, s) { if (!n || n && n.data && (parseInt(n.data.status, 10) !== 302 && parseInt(n.data.status, 10) !== 308)) { ajaxify.updateHistory(e, i) } if (n) { return r(n, e, t, i) } o = true; app.template = s.template.name; require(['translator'], function (n) { n.load(config.defaultLang, s.template.name); a(e, s.template.name, s, t) }) }); return true };
It looks like you could set
i = false
in the click event to cause the link to reload the page instead. Although I don't know how many other paths might also want to useajaxify.go
... it might be better to change that instead, so those will also reload instead of ajax load.
-
@Yamikuronue said in Refreshrefreshrefreshrefresh:
a spinner that appears
But often the reply and upvote buttons stop working without that spinner. And does that spinner show up at all in mobile mode?
-
@NedFodder said in Refreshrefreshrefreshrefresh:
And does that spinner show up at all in mobile mode?
Who knows? There are so many bits of UI that fly in and out and cover up other bits of UI that it could actually be there but invisible. Heck, sometimes it's impossible to even see the reply you're typing, much less some spinner that may or may not be there.
-
@anotherusername said in Refreshrefreshrefreshrefresh:
@accalia I went poking through nodebb.min.js (prettified).
It's too bad the whole project isn't open source or it would be a total to go poking through de-minified JavaScript.
-
immediately followed by
So much for "zero downtime."
-
@blakeyrat said in Refreshrefreshrefreshrefresh:
That's really the issue. Shitty UI. If it just greyed-out the controls in the few seconds it took to reconnect, it'd be a whole lot nicer. Not as good as a non-broken forum, but at least people would KNOW why their 6 paragraph post didn't send suddenly for no reason.
Has this actually been reported--I'm not suggesting you, Blakey, do it--to the nodebb devs? I know we've mentioned it several times here but I don't know if anyone actually filed a bug report about that.
-
@error great, it'll be really easy for someone to find the code I'm talking about there, then.
The de-minified code really isn't that bad. And it's not like finding either of those functions was difficult.
-
@anotherusername said in Refreshrefreshrefreshrefresh:
@error great, it'll be really easy for someone to find the code I'm talking about there, then.
The de-minified code really isn't that bad. And it's not like finding either of those functions was difficult.
-
@ben_lubar if you need help to write a 5 line bash script that restart the dockers when the cpu is at 100% for more than 30s just say the word