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
