I found the issue. Timestamp ordering was broken because: I generated a timestamp for the group of operations. Then, I used hector's remove, which generates its own internal timestamp. I then re-used the timestamp, not wary of the missing timestamp field on the remove operation.
The fix was to simply regenerate my timestamp after any hector operation which generates its own. In my case, hector generates it's own internal timestamp for removes, but not other operations. Until the timestamp resolution is better than milliseconds, it's very possible to end up with the same timestamp for tightly grouped operations, which may lead to unexpected behavior. I've submitted a request to simplify this. On Wed, May 5, 2010 at 5:03 PM, Jonathan Shook <jsh...@gmail.com> wrote: > When I try to replace a set of columns, like this: > > 1) remove all columns under a CF/row > 2) batch insert columns into the same CF/row > .. the columns cease to exist. > > Is this expected? > > This is just across 2 nodes with Replication Factor 2 and Consistency > Level QUOROM. >
