e nature of nanotime you'll run into
>> harder to track down problems, but it may be fine.
>>
>> On Aug 30, 2011, at 2:06 PM, Jiang Chen wrote:
>>
>>> Do you see any problem with my approach to derive the current time in
>>> nano seconds thoug
to measure elapsed
> time and is not related to any other notion of system or wall-clock time."
>
> http://download.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29
>
> On Aug 30, 2011, at 1:31 PM, Jiang Chen wrote:
>
>> Indeed it's microsec
nload.oracle.com/javase/6/docs/api/java/lang/System.html#nanoTime%28%29
>>
>> On Aug 30, 2011, at 12:31 PM, Jiang Chen wrote:
>>
>> > Looks like the theory is correct for the java case at least.
>> >
>> > The default timestamp precision of Pelops is mill
for a few milliseconds didn't help.
It was actually because of the precision of Java Thread.sleep().
Sleeping for less than 15ms often doesn't sleep at all.
Haven't checked the Python side to see if it's similar situation.
Cheers.
Jiang
On Tue, Aug 30, 2011 at 9:57 AM, Jiang C
It's a single node. Thanks for the theory. I suspect part of it may
still be right. Will dig more.
On Tue, Aug 30, 2011 at 9:50 AM, Peter Schuller
wrote:
>> The problem still happens with very high probability even when it
>> pauses for 5 milliseconds at every loop. If Pycassa uses microseconds
>
The problem still happens with very high probability even when it
pauses for 5 milliseconds at every loop. If Pycassa uses microseconds
it can't be the cause. Also I have the same problem with a Java client
using Pelops.
On Tue, Aug 30, 2011 at 12:14 AM, Tyler Hobbs wrote:
>
> On Mon, Aug 29, 201
Hi,
Just started developing using Cassandra (0.8.4). I noticed when
updating the same row and column repeatedly, say, in a test case,
updates may get lost. I found it in a Java client but the following
python script also exhibits the same problem.
*
