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
--
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
