Hi,
It seems to work with these changes:
http://bitbucket.org/tamasnagy/riak/changeset/3908ab72b12b
I've sent a pull request as well.
Regards,
Tamas
Tamas Nagy
Erlang Solutions
http://www.erlang-solutions.com
On 23 Jun 2010, at 20:20, Jon Meredith wrote:
> Thanks for the detailed explanation Tamas, I should have reviewed the
> changeset as well as the commit log.
>
> I'll try and take a look at it this afternoon.
>
> --Jon
>
>
> On 6/23/10 1:09 PM, Tamas Nagy wrote:
>> Hi,
>>
>> I feel that is not going to fix the issue. I can prove it without compiling.
>> (I know He who enters... :) )
>> riak_kv_multi_backend is not a process only riak_kv_vnode is. Hence these
>> messages ({riak_kv_bitcask_backend, merge_check} and
>> {riak_kv_bitcask_backend, {sync, SyncIntervalMs}}):
>>
>> 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}),
>>
>> will be sent to riak_kv_node handle_info (this did not change in the
>> changeset you've linked in):
>>
>> %% @private
>> handle_info(vnode_shutdown, _StateName, StateData) ->
>> {stop,normal,StateData};
>> handle_info(ok, StateName, StateData) ->
>> {next_state, StateName, StateData, ?TIMEOUT};
>> handle_info({Mod, Msg}, StateName, #state { mod = Mod } = StateData) ->
>> Mod:handle_info(StateData#state.modstate, Msg),
>> {next_state, StateName, StateData, ?TIMEOUT}.
>>
>> So the Mod in handle_info will be riak_kv_bitcask_backend but Mod is going
>> to be riak_kv_multi_backend, because of this:
>>
>> init([VNodeIndex]) ->
>> Mod = app_helper:get_env(riak_kv, storage_backend),
>> Configuration = app_helper:get_env(riak_kv),
>> {ok, ModState} = Mod:start(VNodeIndex, Configuration),
>> StateData0 = #state{idx=VNodeIndex,mod=Mod,modstate=ModState,
>> handoff_q=not_in_handoff},
>> case hometest(StateData0) of
>> {next_state, StateName, StateData, Timeout} ->
>> {ok, StateName, StateData, Timeout};
>> {stop,normal,StateData} ->
>> {ok, ModState1} = Mod:start(VNodeIndex, Configuration),
>> {ok, active, StateData#state{mod=Mod, modstate=ModState1},
>> ?TIMEOUT}
>> end.
>>
>> I hope this makes sense. So the linked changeset is a step toward the right
>> direction, but there is still some work left.
>> All three of my possible solutions are based on tip. If I will have time
>> today I will fork the code and show you what I mean.
>>
>> Regards,
>> Tamas
>>
>>
>>
>> ----- "Jon Meredith"<[email protected]> 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"<[email protected]> 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.
>>>>> [email protected]
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jun 23, 2010 at 1:45 PM, Tamas Nagy<
>>>>> [email protected]> 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
>>>>> [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
>>>
>>
>
---------------------------------------------------
---------------------------------------------------
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
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
