It's just not possible to control time, as many super villains and Peter Schuller have shown us http://www.mail-archive.com/user@cassandra.apache.org/msg15636.html
Often it's not necessary, you can design around simultaneous updates the same key, use a coordination layer such as zoo keeper or rely on consensus. If you have a design problem provide some details and someone may be able to help. Cheers ----------------- Aaron Morton Freelance Cassandra Developer @aaronmorton http://www.thelastpickle.com On 26 Jul 2011, at 04:25, Guillermo Winkler wrote: > Hi, thanks both for the answers. > > The problem was indeed with the timestamps. > > What was happening also was that in a mutation involving 1 deletion and > various insertions for the same key, all were using the same timestamp, so > beside looking at the code doing this > > remove key > insert key, col, val > insert key, col, val > insert key, col, val > > With quorum 1, the insertions were always missing. > > I've been reading past threads regarding time sync inside/outside cassandra, > I guess this ain't changing in the near future? > > Best, > Guille > > > On Sun, Jul 24, 2011 at 1:07 PM, Edward Capriolo <edlinuxg...@gmail.com> > wrote: > Remember the cli uses microsecond precision . so if your app is not using the > same precision weird this will result in clients writing the biggest > timsetamp winning the final value. > > > On Saturday, July 23, 2011, Jonathan Ellis <jbel...@gmail.com> wrote: > > You must have given it a delete timestamp in the "future." > > > > On Sat, Jul 23, 2011 at 3:46 PM, Guillermo Winkler > > <gwink...@inconcertcc.com> wrote: > >> I'm having a strange behavior on one of my cassandra boxes, after all > >> columns are removed from a row, insertion on that key stops working (from > >> API and from the cli) > >> [default@Agent] get Schedulers['atendimento']; > >> Returned 0 results. > >> [default@Agent] set Schedulers['atendimento']['test'] = 'dd'; > >> Value inserted. > >> [default@Agent] get Schedulers['atendimento']; > >> Returned 0 results. > >> Already tried nodetool flush/compact/repair on the CF, doesn't fix the > >> problem. > >> With a ver simple setup: > >> * only one node in the cluster (the cluster never had more nodes nor > >> replicas) > >> * random partitioner > >> * CF defined as "create column family Schedulers with > >> comparator=BytesType;" > >> The only way for it to start working again is to truncate the CF. > >> Do you have any clues how to diagnose what's going on? > >> Thanks, > >> Guille > >> > >> > > > > > > > > -- > > Jonathan Ellis > > Project Chair, Apache Cassandra > > co-founder of DataStax, the source for professional Cassandra support > > http://www.datastax.com > > >