Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

skipped days, skipped votes

by pg (Canon)
on Jan 01, 2003 at 22:43 UTC ( #223635=monkdiscuss: print w/ replies, xml ) Need Help??

From time to time, there were people complaining that they were skipped, and didn't get any vote on certain days.

There must be a bug somewhere, should it be fixed? It is not a big deal, but it is better to have a system with less bugs ;-)

Comment on skipped days, skipped votes
Re: skipped days, skipped votes
by rozallin (Curate) on Jan 01, 2003 at 23:03 UTC
    I was always under the impression that every day one monk who was eligible for voting did not receive their allocated votes in a "feature" known as the scapegoat. I can't quite remember where I first read about this but I am sure it was on somemonk's homenode. I myself was the scapegoat on the 12th December.

    -- Rozallin J. Thompson
    The Webmistress who doesn't hesitate to use strict;

      I've heard of it happening as well, but never as a "feature" only affecting one monk per day. If that were the case, then I must be a very lucky monk to experience that "feature" so frequently, including today (01 Jan 2003). It was my understanding instead that it was a minor glitch that occasionally occurred, and generally would only last a day for someone affected (although I believe once I experienced it for two days, but that was some time ago).

        No votes for me today either :-)

        I think everyone was affected in some manner or other on 01 Jan 2003. I got 13 votes which were left over from yesterday; others I have spoken to got none at all.

        I've always considered the glitch to be a "feature" because I came across the following from Vynce's homenode:

        also, on the subject of meaningless data, i was the perlmonks scapegoat for the first time on June 26th, 2001. (The scapegoat is whatever lucky monk on any given day receives no votes despite being entitled to one or more)

        But seeing as how widespread this behaviour seems to have become I think it's probably worth the intervention of the gods to make sure glitches like the one which happened today don't occur frequently, and maybe even having a ballot to see whether we should remove this rather quirky feature from the Monastery anyway. Voting is, after all, a right. :)

        Update: tye explained in the Chatterbox that the process died, which explains why people weren't allocated their fresh votes. Fair enough.

        -- Rozallin J. Thompson
        The Webmistress who doesn't hesitate to use strict;

      If that feature in fact exists, it ought to be removed. I've never heard of it, but I cannot conceive of any rationale that would justify randomly taking away votes, and without an accompanying explanation no less. Now there is a user named scapegoat, with no writeups and only 2 XP who hasn't been here in two years. Perhaps he/she can be the permanent target :^P

      Apparently quite a few of us did not get votes this fine first day of 2003, myself included. So perhaps the scapegoat is taking revenge upon us. Affected users that I know of: pfaut, atcroft, adrianh, blaze, rozallin. /msg me and I'll add usernames to this list. Update: apparently the vote allocating cron job crashed, so it's not a big hoary bug; the problem should be rectified the next time the job runs. So don't /msg me after all, as it won't do any good :^)

      I don't think it's anything quite that sinister rozallin. In the past a lack of votes meant that the 'vote awarding' cronjob failed that's all.

      -- vek --

        Probably a bug if you hit the site just as votes are being given out.

        /me wonders if that was supposed to be "sinister rozalin" (as in a title), "sister rozalin" (a more traditional title), or "sinister, rozalin" (a direct address that happens to be next to an adverb modifying Somthing Completly Different). (Though I'm sure it's not rozalin and not rozallin.) (OK, it's rozallin, not rozalin. I'm wrong.)


        Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Re: skipped days, skipped votes (exactly why)
by tye (Cardinal) on Jan 02, 2003 at 06:00 UTC

    See the Last checked flag not updating? thread for a detailed explanation of why you might not get your votes every once in a while. The discussion is about another type of update but the reason and the explanation are the same for both cases.

    The new-year vote allocation failure was a much rarer problem that probably affected everyone (it looks like the failure was right at the start of the script, but that was a quick look so some might have gotten votes). The job that allocates new votes (aka the vote fairy) failed because the SQL database was too busy.

    I'm investigating.

                    - tye

      Here's an idea.

      Disclaimer: no clue how it really works - I am just under the impression that the vote fairy just blindly crawls the entire nodebase for users.

      Instead, have the vote op add a row to a new table (votequeue or something) with a single column containing the userid. If someone hasn't voted on a day, he won't be added to this queue. The cronjob can then just join on that table to update, and wipe it when done.

      That ought to clip the number of records that have to be updated to maybe a few hundred on a busy day - probably a matter of seconds to process.

      Or am I completely wrong?

      Makeshifts last the longest.

        Two problems. First, if I get promoted on a day I don't vote, I'd rather have my new number of votes when I return rather than my old. So you'd have to modify your plan some to account for that.

        Second, that isn't the problem. (: The vote fairy doesn't take that long to run and it doesn't update any nodes that it doesn't have to. We go through the node cache so that updates get propogated properly to any mod_perl processes that already have your node cached in RAM. Otherwise it might make the problem worse. This means that we update a couple of records that we don't have to and we update lots of fields that we don't have to. But the problem with updating lots of fields that we don't have to is not so much the time required (at least as far as the vote fairy is concerned) but that this leads to the race condition that can overwrite our updates.

        It wasn't that the vote fairy was loading down the SQL server too much. It was that the SQL server was loaded down too much for the vote fairy to even get connected to it. I assume this had something to do with a run-away backup, though that doesn't quite make sense (perhaps the backup load fooled Pair into thinking their was a problem and they restarted the DB). But the backups are not a load problem any longer (I've run them several times during busy periods, like today, now that I've made them gentle like I'd always planned to).

        And I'd rather just fix the node cache to eliminate lots of related problems at the same time.

        Thanks for the suggestion, though. :)

                        - tye

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: monkdiscuss [id://223635]
Approved by TStanley
Front-paged by wil
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (8)
As of 2014-10-31 08:28 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (215 votes), past polls