h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

Jim, take a look at post #16 on this thread: F2693943?thread=5826135&post=68091893#p68091893

It's by someone named (at the moment) "Doughy's Ghost". Click on their name and it takes you to a valid and long list of conversations. Except...

If you look at some of the older conversations they were posted by "Doughy Hood". Refreshing the page doesn't change this.

AFAIK it's still the case that changing your nickname is reflected in every posting you ever made, so it should be impossible for two posts from the same UID to lead to different nicknames...? Is it possible that a Troll or WUM has figured out a way to "spoof" the UID on their posts? I'm pretty certain from the posting styles that "Doughy's Ghost" and "Doughy Hood" are two different people.

Peet

The nickname on a page of posts gets cached so it is possible for older pages to have the previous nickname. You can't spoof uids. So the page with the old name must still be cached and will probably change when the cache expires.

What's the cacheing period? It's still there over 9 hours later.

It could be up to 24 hours, and isn't always 100%. We've had examples where cache files have stayed around longer than they should.

Refreshing http://www.bbc.co.uk/dna/mbarchers/F2693940?thread=5730564 several times, the name keeps changing between "Doughy's Ghost", "Doughy Hood", and "Glenda Slag".

Interesting... I'm pretty sure that's not supposed to happen.

Actually, that's exactly what I would expect. The cache works per server, so if the page is cached on one server but not another, then the name is changed, if the page is then fetched from a different server the name will have changed, but if it is fetched from the one that still has the old page cached you'll see the old name. If the name was changed several times you might well see several different names when refreshing.

Isn't that a hideously inefficient system?

With one server it makes sense to add te overhead of cacheing a page because you know the user will hit that server if they return. With (n) servers, though, the cacheing is less effective because even with a cached page any request only has a 1/n chance of hitting the cached copy, and an (n-1)-in-n chance of having to go through the whole cacheing process again. And as has been demonstrated, as te number of servers increases so does the chances of unsynchronised cache copies.

(te = the - keyboard needs new batteries.)

It's a simple caching system originally designed when we had only two servers (or maybe even one). We get a fair amount of value out of it, when we measure it, so until we get the funding to develop a better mechanism, it'll do.