Instructions for building Riak from source are available here: https://wiki.basho.com/display/RIAK/Installing+Riak+from+Source
You will want to follow the instructions "Installing from Bitbucket". Daniel Reverri Developer Advocate Basho Technologies, Inc. d...@basho.com On Wed, Jun 23, 2010 at 2:43 PM, Jon Meredith <jmered...@basho.com> wrote: > Hi Tamas, > > Are you using the 0.11.0 release? We found an issue with the multi backend > a few days ago detailed here http://issues.basho.com/show_bug.cgi?id=274 . > It should be fixed in tip after this change > http://bitbucket.org/basho/riak/changeset/bf66258beaac > > You'll have to build from source source and check if that resolves your > issue? > > --Jon Meredith > Basho Technologies > > > On 6/23/10 12:36 PM, Tamas Nagy wrote: > >> Hi, >> >> Thanks for the link. Should I create a ticket there from this thread? >> >> Well the error I saw was this (actually a lot of these because of the >> restarts): >> >> =ERROR REPORT==== 23-Jun-2010::12:40:34 === >> ** State machine<0.201.0> terminating >> ** Last message in was {riak_kv_bitcask_backend,merge_check} >> ** When State == active >> ** Data == {state,0,[],riak_kv_multi_backend, >> {state, >> [{riak_ets,riak_kv_ets_backend,<0.203.0>}, >> {riak_bitcask,riak_kv_bitcask_backend, >> {#Ref<0.0.0.762>,"data/bitcask/0"}}], >> riak_ets}, >> not_in_handoff,undefined} >> ** Reason for termination = >> ** {function_clause, >> [{riak_kv_vnode,handle_info, >> [{riak_kv_bitcask_backend,merge_check}, >> active, >> {state,0,[],riak_kv_multi_backend, >> {state, >> [{riak_ets,riak_kv_ets_backend,<0.203.0>}, >> {riak_bitcask,riak_kv_bitcask_backend, >> {#Ref<0.0.0.762>,"data/bitcask/0"}}], >> riak_ets}, >> not_in_handoff,undefined}]}, >> {gen_fsm,handle_msg,7}, >> {proc_lib,init_p_do_apply,3}]} >> >> So as you can see riak_kv_vnode cannot handle riak_kv_bitcask_backend >> messages ({riak_kv_bitcask, Whatever}) if the backend type is >> riak_kv_multi_backend. There is simply no case for it in the handle_info >> callback of riak_kv_vnode module. In the current handle_info cases the Mod >> tag of the message has to be the same as the value of the state's mod >> element. One of the possible fixes relaxes this check. >> >> Regards, >> Tamas >> >> ----- "Dan Reverri"<d...@basho.com> wrote: >> >> >> >>> Hi Tamas, >>> >>> >>> You can find the public bug tracker here: >>> https://issues.basho.com/ >>> >>> >>> Regarding using Bitcask with multiple backends, the only issue I've >>> seen is trying to setup multiple bitcask backends. Bitcask defines >>> options using the "bitcask" application specification which is >>> globally set for the node; this prevents multiple instances of the >>> bitcask backend from running on a single node: >>> https://issues.basho.com/show_bug.cgi?id=210 >>> >>> >>> You should be able to run a bitcask backend along side other backend >>> types such as dets. >>> >>> >>> I did not completely follow your description; what issues did you see >>> after setting bitcask as a backend in the multibackend options? Were >>> keys not stored? Did you see errors in the log files? Did you try to >>> setup multiple bitcask backends? >>> >>> >>> Thanks, >>> Dan >>> >>> Daniel Reverri >>> Developer Advocate >>> Basho Technologies, Inc. >>> d...@basho.com >>> >>> >>> >>> On Wed, Jun 23, 2010 at 1:45 PM, Tamas Nagy< >>> tamas.n...@erlang-solutions.com> wrote: >>> >>> >>> Hi, >>> >>> I'm pretty new to the list (and riak) so please forgive my ignorance >>> but I didn't manage to find a public bugtracker for riak. Hence I'm >>> posting my problem here. (Bitbucket and Internet Explorer(using it not >>> by choice) do not mix well. So that might be the problem why I didn't >>> find it). >>> >>> I've tried to use riak_kv_multi_backend with one of the backends being >>> the riak_kv_bitcask_backend. This does not seem to work with >>> riak-0.11.0. I checked tip as well, and I do not think it would work >>> either. The problem boils to these few lines (code snippets from tip): >>> >>> riak_kv_vnode: >>> >>> handle_info({Mod, Msg}, StateName, #state { mod = Mod } = StateData) >>> -> >>> Mod:handle_info(StateData#state.modstate, Msg), >>> {next_state, StateName, StateData, ?TIMEOUT}. >>> >>> riak_kv_bitcask_backend: >>> >>> start(Partition, _Config) -> >>> %% Schedule sync (if necessary) >>> case application:get_env(bitcask, sync_strategy) of >>> {ok, {seconds, Seconds}} -> >>> SyncIntervalMs = timer:seconds(Seconds), >>> erlang:send_after(SyncIntervalMs, self(), >>> {?MODULE, {sync, SyncIntervalMs}}); >>> _ -> ok end, >>> %% Schedule merge checks >>> erlang:send_after(?MERGE_CHECK_INTERVAL, self(), {?MODULE, >>> merge_check}), >>> >>> >>> riak_kv_multi_backend: >>> >>> handle_info(State, Msg) -> >>> F = fun(_Name, Module, SubState) -> >>> Module:handle_info(SubState, Msg) >>> end, [F(X) || X<- State#state.backends], >>> ok. >>> >>> If riak_kv_multi_backend is configured in riak_kv_vnode the state's >>> mod is riak_kv_multi_backend but the messages scheduled in >>> riak_kv_bitcask_backend are going to have riak_kv_bitcask_backend as >>> their Mod tag. >>> >>> With my limited understanding about the rest of the sytem it seems to >>> me that adding this case to riak_kv_vnode would fix the problem: >>> handle_info({Mod, Msg}, StateName, #state { mod = >>> riak_kv_multi_backend } = StateData) -> >>> riak_kv_multi_backend:handle_info(StateData#state.modstate, Msg), >>> {next_state, StateName, StateData, ?TIMEOUT}; >>> >>> It is a bit wasteful because all the configured backends will get >>> called with this message, but it is the best I can think of without >>> leaking too much information about the specific backends into the >>> generic code. >>> >>> Modifying the handle_info case would work as well however one check >>> would need to disappear: >>> >>> handle_info({_ModTag, Msg}, StateName, #state { mod = Mod } = >>> StateData) -> >>> Mod:handle_info(StateData#state.modstate, Msg), >>> {next_state, StateName, StateData, ?TIMEOUT}. >>> >>> There are a plethora of other ways to fix this like passing the Mod >>> tag to riak_kv_multi_backend so that it can filter based on it (this >>> is probably my favourite as it is not wasteful and there aren't many >>> code changes needed either): >>> riak_kv_vnode: >>> handle_info({Mod, Msg}, StateName, #state { mod = >>> riak_kv_multi_backend } = StateData) -> >>> riak_kv_multi_backend:handle_info(StateData#state.modstate, {Mod, >>> Msg}), >>> {next_state, StateName, StateData, ?TIMEOUT}; >>> >>> riak_kv_multi_backend: >>> handle_info(State, {Mod, Msg}) -> >>> F = fun(_Name, Module, SubState) -> >>> Module:handle_info(SubState, Msg) >>> end, [F(X) || X = {_, Module, _}<- State#state.backends, >>> Module =:= Mod], >>> ok. >>> >>> Code is not tested, but should compile. :) >>> >>> Regards, >>> Tamas >>> >>> -- >>> Tamas Nagy >>> Erlang Solutions Ltd. >>> http://www.erlang-solutions.com >>> --------------------------------------------------- >>> >>> --------------------------------------------------- >>> >>> WE'VE CHANGED NAMES! >>> >>> Since January 1st 2010 Erlang Training and Consulting Ltd. has become >>> ERLANG SOLUTIONS LTD. >>> >>> www.erlang-solutions.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
