• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Are ATOT forums load balanced?

I'm just curious how the forums are allowing time warps. If there are multiple front end servers processing the requests and their clocks are out of sync, then perhaps that could be causing the time warps? If the code to insert the replies is relying on the clock of the webserver and not the database server it is applying the changes to, or if there are multiple db servers and their clocks aren't in sync, that could be causing the problem..

Just wondering...... ... . .. .
 

Crusty

Lifer
I think the answer lies in the fact that the forums are running Fusetalk. Take traditional logic and throw it out the door, because that's what the developers of it did with their brain when they decided to write the code.
 
Originally posted by: TechBoyJK
I'm just curious how the forums are allowing time warps. If there are multiple front end servers processing the requests and their clocks are out of sync, then perhaps that could be causing the time warps? If the code to insert the replies is relying on the clock of the webserver and not the database server it is applying the changes to, or if there are multiple db servers and their clocks aren't in sync, that could be causing the problem..

Just wondering...... ... . .. .

There isn't enough traffic here to require multiple DB servers unless they're old and crummy, or FT is coded badly.
Either way, it ain't hard to set up servers to sync time.
 
My understanding is that the DB server clock is out of sync with the Webserver causing the problem, but my opinion doesn't mean much
 
Originally posted by: nakedfrog
Originally posted by: TechBoyJK
I'm just curious how the forums are allowing time warps. If there are multiple front end servers processing the requests and their clocks are out of sync, then perhaps that could be causing the time warps? If the code to insert the replies is relying on the clock of the webserver and not the database server it is applying the changes to, or if there are multiple db servers and their clocks aren't in sync, that could be causing the problem..

Just wondering...... ... . .. .

There isn't enough traffic here to require multiple DB servers unless they're old and crummy, or FT is coded badly.
Either way, it ain't hard to set up servers to sync time.

I know it's not hard, but I'm just wondering if that could be the cause. I've seen some pretty basic things get overlooked and cause big problems
 
Originally posted by: spidey07
Nobody is dumb enough to not be using NTP for clocks.

For sure. But.. How the fuck could time ordered inserts be displayed out of order? Timestamps can be very precise...
 
Originally posted by: nakedfrog
Originally posted by: TechBoyJK
I'm just curious how the forums are allowing time warps. If there are multiple front end servers processing the requests and their clocks are out of sync, then perhaps that could be causing the time warps? If the code to insert the replies is relying on the clock of the webserver and not the database server it is applying the changes to, or if there are multiple db servers and their clocks aren't in sync, that could be causing the problem..

Just wondering...... ... . .. .

There isn't enough traffic here to require multiple DB servers unless they're old and crummy, or FT is coded badly.
Either way, it ain't hard to set up servers to sync time.

yeah i think you hit the nail on squarely on the head with that one.
 
If the FT code is doing an SQL INSERT into the back-end database via ODBC or some other database connection using a call to get the time on the local server receiving the HTTP POST to pass as a function parameter, then the race condition is obvious.
 
They just need to heighten the load module and reboot the sychronizer. Maybe even reverse the polarity of the frequency gauge.


Everyone knows this.
 
They are putting all their work into the site redesign and switchover to vB, so they are just letting the current bugs go for now.
 
Originally posted by: Locut0s
They are putting all their work into the site redesign and switchover to vB, so they are just letting the current bugs go for now.
This. They quit paying FuseTalk for support when they decided to switch. So they are a few updates behind.

 
lol, how fitting. Crusty gets time warped in a thread talking about suggestions on how to fix the time warping.
 
Originally posted by: rockyct
lol, how fitting. Crusty gets time warped in a thread talking about suggestions on how to fix the time warping.

I didn't even try on this one either 🙁
 
Originally posted by: her209
If the FT code is doing an SQL INSERT into the back-end database via ODBC or some other database connection using a call to get the time on the local server receiving the HTTP POST to pass as a function parameter, then the race condition is obvious.

I can't imagine why you'd use anything other than the DB time, though.
 
Originally posted by: phoenix79
My understanding is that the DB server clock is out of sync with the Webserver causing the problem, but my opinion doesn't mean much

Same here.

But the better reason is most likely a mysql slave is out of sync with the master time wise, and the functions aren't deterministic.
 
If you don't get stingy with the reach-arounds, the perv mod gives you a time warp accelerator for your browser.

 
Originally posted by: OCguy
They just need to heighten the load module and reboot the sychronizer. Maybe even reverse the polarity of the frequency gauge.


Everyone knows this.


Sometimes that causes more problems than it is worth. Duh.
 
i love timewarping... it allows me to go from hitting on a chick here on ATOT to already banging her without any other steps...
 
Originally posted by: her209
If the FT code is doing an SQL INSERT into the back-end database via ODBC or some other database connection using a call to get the time on the local server receiving the HTTP POST to pass as a function parameter, then the race condition is obvious.

I'm not saying you're wrong, this would definitely cause warps, but who in their right mind would ever code something this way?
 
Originally posted by: Legendary
Originally posted by: her209
If the FT code is doing an SQL INSERT into the back-end database via ODBC or some other database connection using a call to get the time on the local server receiving the HTTP POST to pass as a function parameter, then the race condition is obvious.
I'm not saying you're wrong, this would definitely cause warps, but who in their right mind would ever code something this way?
Maybe it was never intended for it to be run on multiple front-end servers.
 
Back
Top