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