I've sent a second message stating that the same happens locally if I set the attributes described in the bucket type.
Thanks, Valter Em 26/11/2013 18:16, "Jordan West" <jw...@basho.com> escreveu: > Valter, > > A Riak cluster, using strongly consistent operations or otherwise, is not > meant to be setup with nodes across data centers/AWS regions/etc. Riak > Enterprise [1] is meant to be used with multiple Riak clusters to replicate > over a WAN. Unfortunately, it does not yet support strong consistency, and > I don't have many more details I can share at this time. > > Jordan > > [1] http://docs.basho.com/riakee/latest/ > > > On Tue, Nov 26, 2013 at 4:25 AM, Valter Balegas <bale...@gmail.com> wrote: > >> It also gives me the time-out, when i run one node locally, if i create >> the bucket type like this: >> >> ./riak-admin bucket-type create STRONG '{"props": {"consistent":true, >> "n_val":1, "last_write_wins":true}}’ >> >> Valter >> >> >> No dia 26/11/2013, às 02:20, Mark Phillips <m...@basho.com> escreveu: >> >> Hi Valter, >> >> >> On Mon, Nov 25, 2013 at 4:47 PM, Valter Balegas <bale...@gmail.com> >> wrote: >> >>> Hello, >>> >>> I’m trying to use strong consistency in a riak cluster with nodes in a >>> wide-area network, but a timeout fires sometimes, regardless the timeout >>> value. >>> >> >> How many nodes do you have? And where are they located geographically? >> >> >> >>> I tried to increase the timeout of the get operation but it does not >>> seem to help. Is there any parameter that i can change to increase the >>> timeout? >>> The latency between the nodes is the order of hundreds of milliseconds, >>> and, since in the eventual-consistency setting this does not happen (even >>> with a bigger read quorum), i’m assuming it has to do with Strong >>> consistency parametrization. >>> I’m using the most recent erlang client and riak versions and the client >>> runs in the same machine as the node i connect to. >>> >>> {ok, Pid} = riakc_pb_socket:start_link(“NODELINK", 8087). >>> {ok,<0.35.0>} >>> 2> >>> 2> riakc_pb_socket:get(Pid, {<<"STRONG">>,<<"ITEMS">>}, <<"KEY">>, >>> [],5000). >>> {error,<<"timeout">>} >>> 3>riakc_pb_socket:get(Pid, {<<"STRONG">>,<<"ITEMS">>}, <<"KEY">>, >>> [],5000). >>> {ok,{riakc_obj,{<<"STRONG">>,<<"ITEMS">>}, >>> <<"KEY">>, >>> <<107,206,97,96,96,96,204,96,74,97,96,73,45,78,45,204,96, >>> 202,99,99,96,1,10,...>>, >>> [{{dict,2,16,16,8,80,48, >>> {[],[],[],[],[],[],[],[],[],[],[],[],...}, >>> {{[],[],[],[],[],[],[],[],[],[],...}}}, >>> <<"100">>}], >>> undefined,undefined}} >>> 4> riakc_pb_socket:get(Pid, {<<"STRONG">>,<<"ITEMS">>}, <<"KEY">>, >>> [],5000000). >>> {error,<<"timeout">>} >>> 5> riakc_pb_socket:get(Pid, {<<"STRONG">>,<<"ITEMS">>}, <<"KEY">>, >>> [],5000). >>> >>> =ERROR REPORT==== 26-Nov-2013::00:34:38 === >>> ** Generic server <0.35.0> terminating >>> ** Last message in was {req_timeout,#Ref<0.0.0.113>} >>> ** When Server state == {state,”NODELINK", >>> >>> 8087,false,false,undefined,gen_tcp,undefined, >>> {[],[]}, >>> >>> 1,[],infinity,undefined,undefined,undefined, >>> undefined,100} >>> ** Reason for termination == >>> ** disconnected >>> ** exception exit: disconnected >>> >>> Thanks, >>> Valter >>> >>> >>> >>> No dia 21/11/2013, às 11:40, Valter Balegas <bale...@gmail.com> >>> escreveu: >>> >>> Thanks, it works now! >>> i wouldn’t realize that bucket type had to be specified as a type. But i >>> did say that i didn’t now what that meant. :) >>> >>> I hope i can do all my experiments now, >>> Valter >>> >>> No dia 20/11/2013, às 21:04, Valter Balegas <bale...@gmail.com> >>> escreveu: >>> >>> Hello, >>> >>> Here is the sequence of commands: >>> >>> --Compiled Riak with "make rel" and riak-erlang-client with “make". >>> Erlang version R16B02; using the latest version on GitHub or the >>> riak2.0.0.5pre package. >>> >>> ./bin/riak stop >>> >>> --changed the consensus flag to true on ./etc/riak.conf >>> >>> ./bin/riak start >>> >>> .bin//riak-admin bucket-type create bucket '{"props": {"consistent": >>> true}}' >>> ./bin/riak-admin bucket-type activate bucket >>> >>> ./bin/riak stop >>> ./bin/riak start >>> >>> on a erlang console, initialized with: >>> >>> ./erts-5.10.3/bin/erl -pa ../riak-erlang-client/ebin >>> ../riak-erlang-client/deps/*/ebin >>> >>> f(Pid), {ok, Pid} = riakc_pb_socket:start_link("localhost", 8087). >>> NewA = riakc_obj:new(<<"bucket">>, <<"key">>, <<"my binary data">>). >>> NewB = riakc_obj:new(<<"bucket">>, <<"key">>, <<"my other binary >>> data">>). >>> riakc_pb_socket:put(Pid, NewA, [return_body]). >>> {ok,{riakc_obj,<<"bucket">>,<<"key">>, >>> <<107,206,97,96,96,96,204,96,202,5,82,28,202,156,255,126, >>> 6,245,74,255,202,96,74,...>>, >>> [{{dict,2,16,16,8,80,48, >>> {[],[],[],[],[],[],[],[],[],[],[],[],...}, >>> {{[],[],[],[],[],[],[],[],[],[],...}}}, >>> <<"my binary data">>}], >>> undefined,undefined}} >>> 5> riakc_pb_socket:put(Pid, NewB, [return_body]). >>> {ok,{riakc_obj,<<"bucket">>,<<"key">>, >>> <<107,206,97,96,96,96,204,96,202,5,82,28,202,156,255,126, >>> 6,245,74,255,202,96,74,...>>, >>> [{{dict,2,16,16,8,80,48, >>> {[],[],[],[],[],[],[],[],[],[],[],[],...}, >>> {{[],[],[],[],[],[],[],[],[],[],...}}}, >>> <<"my binary data">>}, >>> {{dict,2,16,16,8,80,48, >>> {[],[],[],[],[],[],[],[],[],[],[],...}, >>> {{[],[],[],[],[],[],[],[],[],...}}}, >>> <<"my other binary data">>}], >>> undefined,undefined}} >>> >>> bin/riak-admin bucket-type status bucket >>> bucket is active >>> >>> young_vclock: 20 >>> w: quorum >>> small_vclock: 50 >>> rw: quorum >>> r: quorum >>> pw: 0 >>> precommit: [] >>> pr: 0 >>> postcommit: [] >>> old_vclock: 86400 >>> notfound_ok: true >>> n_val: 3 >>> linkfun: {modfun,riak_kv_wm_link_walker,mapreduce_linkfun} >>> last_write_wins: false >>> dw: quorum >>> consistent: true >>> chash_keyfun: {riak_core_util,chash_std_keyfun} >>> big_vclock: 50 >>> basic_quorum: false >>> allow_mult: true >>> active: true >>> claimant: 'riak@127.0.0.1 >>> >>> bin/riak-admin bucket-type list >>> bucket (active) >>> >>> >>> >>> No dia 20/11/2013, às 17:23, Jordan West <jw...@basho.com> escreveu: >>> >>> Hi Valter, >>> >>> Could you provide the code you are using to generate the concurrent >>> requests in addition to the output of `riak-admin bucket-type list` and >>> `riak-admin bucket-type status <buckettype>` where <buckettype> is the name >>> of the strongly consistent bucket you created (from one node should be >>> sufficient)? I've been using this feature in a personal project and just >>> tested on a local cluster using curl and was unable to reproduce (the >>> cluster was a bit behind develop but there have been no recent changes to >>> the feature). >>> >>> Cheers, >>> Jordan >>> >>> >>> On Wed, Nov 20, 2013 at 5:30 AM, Valter Balegas <bale...@gmail.com> >>> wrote: >>> >>>> Hello, >>>> >>>> I was able to activate strong consistency, but the node keeps >>>> generating siblings, when i execute two concurrent writes (Store two >>>> objects without vector clock). >>>> I tried with the Riak 2.0.0.5pre package and the latest version on the >>>> repository. Am i missing anything? i was expecting operations to fail, in >>>> this case. >>>> >>>> It seems that the error was caused by my Erlang version. The creation >>>> of the bucket type didn’t fail with R16B02. >>>> >>>> Valter >>>> >>>> No dia 20/11/2013, às 03:13, Jordan West <jw...@basho.com> escreveu: >>>> >>>> Valter, >>>> >>>> You mentioned you are using a recent develop. Would you be able to pull >>>> down any recent changes and update-deps (or build a fresh devrel)? I just >>>> tried a fresh clone of develop and was unable to reproduce the same error. >>>> I, also, tried with R15B01 (Riak 2.0 is slated to use R16B02 right now). >>>> >>>> Alternatively, you should be able to workaround this by doing a `riak >>>> attach-direct` and defining the atom at the erlang shell: >>>> >>>> 1> consistent. >>>> consistent >>>> >>>> Jordan >>>> >>>> >>>> On Tue, Nov 19, 2013 at 3:06 PM, Valter Balegas <bale...@gmail.com> >>>> wrote: >>>> >>>>> I can’t create the bucket type: >>>>> >>>>> RPC to 'riak@127.0.0.1' failed: {'EXIT', >>>>> {badarg, >>>>> [{erlang,list_to_existing_atom, >>>>> ["consistent"], >>>>> []}, >>>>> >>>>> {riak_kv_wm_utils,erlify_bucket_prop,1, >>>>> >>>>> [{file,"src/riak_kv_wm_utils.erl"}, >>>>> {line,393}]}, >>>>> {riak_kv_console, >>>>> >>>>> '-bucket_type_create/2-lc$^0/1-0-',1, >>>>> [{file,"src/riak_kv_console.erl"}, >>>>> {line,483}]}, >>>>> >>>>> {riak_kv_console,bucket_type_create,2, >>>>> [{file,"src/riak_kv_console.erl"}, >>>>> {line,483}]}, >>>>> {rpc,'-handle_call_call/6-fun-0-',5, >>>>> [{file,"rpc.erl"},{line,203}]}]}} >>>>> >>>>> I activated the consensus in riak.conf in the etc dir (find command >>>>> seems not to find the pattern anywhere else). >>>>> Is there any other way to create the bucket? >>>>> >>>>> Valter >>>>> >>>>> No dia 19/11/2013, às 18:10, Jordan West <jw...@basho.com> escreveu: >>>>> >>>>> On Tue, Nov 19, 2013 at 7:33 AM, Valter Balegas <bale...@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> Strong consistency: >>>>>> How does one activate this? As i understand, either the pb or the >>>>>> http clients do not accept the consistent property. >>>>>> >>>>>> >>>>> Using strong consistency in the Tech Preview is a two-step process. >>>>> First, turn on the feature in your riak.conf (the following command >>>>> assumes >>>>> you are using a devrel): >>>>> >>>>> for d in dev/dev*; do sed -e 's/## enable_consensus = >>>>> true/enable_consensus = true/' -i $d/etc/riak.conf; done >>>>> >>>>> Then re(start) the cluster. >>>>> >>>>> With the enable_consensus=true un-commented and the cluster running >>>>> create a strongly consistent bucket type: >>>>> >>>>> riak-admin bucket-type create <type name> '{"props": {"consistent": >>>>> true}}' >>>>> riak-admin bucket-type activate <type name> >>>>> >>>>> You can create and activate the bucket type without having >>>>> enabled_consensus=true but both must be done to work with strongly >>>>> consistent data. >>>>> >>>>> Once that is done you can make requests, just like you would to >>>>> eventually consistent data in Riak, but the semantics will be different. >>>>> For example, if you make two PUT requests to the same key, w/ no vector >>>>> clock*, the second request will fail because the data already exists. More >>>>> details on semantics of strongly consistent requests can be found in this >>>>> PR: https://github.com/basho/riak_kv/pull/710 >>>>> >>>>> Hope that helps get you started, >>>>> >>>>> Jordan >>>>> >>>>> * in strong consistency, the "vector clock" is not really a vector >>>>> clock. its called such for familiarity, but like any real vector clock >>>>> exposed to the client, should be treated like an opaque context. >>>>> >>>>> >>>>>> Details about my environment: >>>>>> -I’m running Mac OSX 10.9 >>>>>> -Erlang R15B01 >>>>>> -Compiling riak “develop” branch, from basho github >>>>>> -Compiling riak-erlang-client “master” branch, from basho github. >>>>>> -recompiled the latest versions of the branches just before writing >>>>>> this email. >>>>>> >>>>>> >>>>>> Thank you for your help, >>>>>> Valter >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> riak-users mailing list >>>>>> riak-users@lists.basho.com >>>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> riak-users mailing list >>> riak-users@lists.basho.com >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >> >> >> _______________________________________________ >> riak-users mailing list >> riak-users@lists.basho.com >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >> >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
