I'm currently using the java client and its ConflictResolver and Mutator interfaces. In some cases I am just doing a store, and letting the client do an implicit fetch and the mutator to make the actual change. In other cases I'm doing an explicit fetch, modify the result, and then a store without fetch. For both, I am using a ConflictResolver and I have added a field for the vclock and used the annotation in my beans.
I'll try pointing a local client at the cluster to see if I can see how many siblings there are. That is, if I can get the cluster running again...:) Paul Paul Ingalls Founder & CEO Fanzo [email protected] @paulingalls http://www.linkedin.com/in/paulingalls On Aug 5, 2013, at 9:36 PM, Jeremy Ong <[email protected]> wrote: > On the client you could extract the value_count of the objects you > read and just log them. Feel free to post code too, in particular, how > you are writing out updated values. > > On Mon, Aug 5, 2013 at 9:20 PM, Paul Ingalls <[email protected]> wrote: >> Interesting. I have sibling resolution code on the client side. Would >> sibling explosion take out the entire cluster all at once? Within 5 minutes >> of my last email, the rest of the cluster died. >> >> Is there a way to quickly figure out whether the cluster is full of >> siblings? >> >> Paul Ingalls >> Founder & CEO Fanzo >> [email protected] >> @paulingalls >> http://www.linkedin.com/in/paulingalls >> >> On Aug 5, 2013, at 8:07 PM, Evan Vigil-McClanahan <[email protected]> >> wrote: >> >> Given your leveldb settings, I think that compaction is an unlikely >> culprit. But check this out: >> >> 2013-08-05 18:01:15.878 [info] <0.83.0>@riak_core_sysmon_ >> handler:handle_event:92 monitor large_heap <0.14832.557> >> [{initial_call,{riak_kv_get_fsm,init,1}},{almost_current_function,{riak_object,encode_maybe_binary,1}},{message_queue_len,1}] >> [{old_heap_block_size,0},{heap_block_size,116769640},{mbuf_size,0},{stack_size,52},{old_heap_size,0},{heap_size,81956791}] >> >> That's a 78MB heap in encode object... Unless your objects are big, I >> would suspect sibling explosion caused by rapid updates at w = 1. >> >> >> >> _______________________________________________ >> riak-users mailing list >> [email protected] >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
