Well, on windows Vista and below (haven't checked on 7), System.currentTimeMillis only has around 10ms granularity. That is for any 10ms period, you get the same value. I develop on Windows and I'd get sporadic integration test failures due to this.

On Thu, Sep 1, 2011 at 8:31 PM, Jeremiah Jordan <jeremiah.jordan@morningstar.com> wrote:
Are you running on windows?  If the default timestamp is just using time.time()*1e6 you will get the same timestamp twice if the code is close together.  time.time() on windows is only millisecond resolution.  I don't use pycassa, but in the Thrift api wrapper I created for our python code I implemented the following function for getting timestamps:

def GetTimeInMicroSec():
   Returns the current time in microseconds, returned value always increases with each call.

   :return: Current time in microseconds
   newTime = long(time.time()*1e6)
       if GetTimeInMicroSec.lastTime >= newTime:
           newTime = GetTimeInMicroSec.lastTime + 1
   except AttributeError:
   GetTimeInMicroSec.lastTime = newTime
   return newTime

On 08/29/2011 04:56 PM, Peter Schuller wrote:
If the client sleeps for a few ms at each loop, the success rate
increases. At 15 ms, the script always succeeds so far. Interestingly,
the problem seems to be sensitive to alphabetical order. Updating the
value from 'aaa' to 'bbb' never has problem. No pause needed.
Is it possible the version of pycassa you're using does not guarantee
that successive queries use non-identical and monotonically increasing
timestamps? I'm just speculating, but if that is the case and two
requests are sent with the same timestamp (due to resolution being
lower than the time it takes between calls), the tie breaking would be
the column value which jives with the fact that you're saying it seems
to depend on the value.

(I haven't checked current nor past versions of pycassa to determine
if this is plausible. Just speculating.)

Paul Loy