Bill, I've been having that same IT issue and said the same thing "It's not happening to others". I lifted the timeout completely and it never finished.
On Wed, Sep 24, 2014 at 1:13 PM, Mike Drob <[email protected]> wrote: > Any chance the IRC chats can make it only the ML for posterity? > > Mike > > On Wed, Sep 24, 2014 at 12:04 PM, Keith Turner <[email protected]> wrote: > > > On Wed, Sep 24, 2014 at 12:44 PM, Russ Weeks <[email protected]> > > wrote: > > > > > Interesting that "y" (0x79) and "9" (0x39) are one bit "away" from each > > > other. I blame cosmic rays! > > > > > > > It is interesting, and thats only half of the story. Its been > interesting > > chatting w/ Josh about this on irc and hearing about his findings. > > > > > > > > > > On Wed, Sep 24, 2014 at 9:05 AM, Josh Elser <[email protected]> > > wrote: > > > > > > > > > > >>> The offending keys are: > > > >>> > > > >>> 389a85668b6ebf8e 2ff6:4a78 [] 1411499115242 > > > >>> > > > >>> 3a10885b-d481-4d00-be00-0477e231ey65:000000008576b169: > > > >>> 0cd98965c9ccc1d0:ba15529e > > > >>> > > > >> > > > > The careful eye will notice that the UUID in the first component of > the > > > > value has a different suffix than the next corrupt key/value (ends > with > > > > "ey65" instead of "e965"). Fixing this in the Value and re-running > the > > > CRC > > > > makes it pass. > > > > > > > > > > > > and > > > >>> > > > >>> 7e56b58a0c7df128 5fa0:6249 [] 1411499311578 > > > >>> > > > >>> 3a10885b-d481-4d00-be00-0477e231e965:0000p000872d60eb: > > > >>> 499fa72752d82a7c:5c5f19e8 > > > >>> > > > >>> > > > > > >
