incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremiah Jordan <jeremiah.jor...@morningstar.com>
Subject Re: Updates lost
Date Thu, 01 Sep 2011 19:31:04 GMT
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)
     try:
         if GetTimeInMicroSec.lastTime >= newTime:
             newTime = GetTimeInMicroSec.lastTime + 1
     except AttributeError:
         pass
     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.)
>

Mime
View raw message