Timeout when storing

[Jim Adler]

After successfully getting and storing several objects in a loop, I eventually 
get a timeout when storing a small object.  I'm using the python client and 
protocol buffers. Is the node corrupted somehow? I'm running a single node 
cluster on Ubuntu 11.04 (natty), 32-bit machine.

Here's the traceback:

  File "twitter_crawl.py", line 317, in main
new_obj.store(return_body=True)
  File 
"/usr/local/lib/python2.7/dist-packages/riak-1.3.0-py2.7.egg/riak/riak_object.py",
 line 296, in store
Result = t.put(self, w, dw, return_body)
  File 
"/usr/local/lib/python2.7/dist-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
 line 188, in put
msg_code, resp = self.recv_msg()
  File 
"/usr/local/lib/python2.7/dist-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
 line 370, in recv_msg
raise Exception(msg.errmsg)
Exception: timeout
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

RE: Timeout when storing

[Jim Adler]

I don't know if this is related, but the node wont backup either.  Below
is the error when riak-admin backup is run.  Is my node a goner?  If so,
is there any recovery possible?

Thanks.

{"init terminating in
do_boot",{{{badmatch,{error,{{badmatch,{error,emfile}},[{bitcask,scan_ke
y_files,3},{bitcask,init_keydir,2},{bitcask,open,2},{riak_kv_bitcask_bac
kend,start,2},{riak_kv_vnode,init,1},{riak_core_vnode,init,1},{gen_fsm,i
nit_it,6},{proc_lib,init_p_do_apply,3}]}}},[{riak_core_vnode_master,get_
vnode,2},{riak_core_vnode_master,handle_call,3},{gen_server,handle_msg,5
},{proc_lib,init_p_do_apply,3}]},{gen_server,call,[{riak_kv_vnode_master
,'riak@127.0.0.1'},{spawn,{riak_vnode_req_v1,188396695437186704299693747
96758002522554368,{server,undefined,undefined},{riak_core_fold_req_v
1,#Fun,<0.78.0>}}},infinity]}}}
init terminating in do_boot ()

-----Original Message-
From: Jim Adler 
Sent: Thursday, September 29, 2011 8:17 AM
To: riak-users@lists.basho.com
Subject: Timeout when storing

After successfully getting and storing several objects in a loop, I
eventually get a timeout when storing a small object.  I'm using the
python client and protocol buffers. Is the node corrupted somehow? I'm
running a single node cluster on Ubuntu 11.04 (natty), 32-bit machine.

Here's the traceback:

  File "twitter_crawl.py", line 317, in main
new_obj.store(return_body=True)
  File
"/usr/local/lib/python2.7/dist-packages/riak-1.3.0-py2.7.egg/riak/riak_o
bject.py", line 296, in store
Result = t.put(self, w, dw, return_body)
  File
"/usr/local/lib/python2.7/dist-packages/riak-1.3.0-py2.7.egg/riak/transp
orts/pbc.py", line 188, in put
msg_code, resp = self.recv_msg()
  File
"/usr/local/lib/python2.7/dist-packages/riak-1.3.0-py2.7.egg/riak/transp
orts/pbc.py", line 370, in recv_msg
raise Exception(msg.errmsg)
Exception: timeout

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

RE: Timeout when storing

[Jim Adler]

Thanks Sean.  I added the ulimit -n 10240 to /etc/default/riak, restarted riak, 
but that didn't work. 

Fyodor Yarochkin suggested that the bitcask files could be corrupted, but I 
wasn't sure which bitcask *.data or *.hint file to delete.  Any pointers?

Here's the /var/log/riak/erlang.log:

=ERROR REPORT 29-Sep-2011::20:27:42 ===
** State machine <0.369.0> terminating 
** Last event in was {riak_vnode_req_v1,
  94198347718593352149846873983790012612771840,
  {fsm,undefined,<0.27704.1>},
  {riak_kv_put_req_v1,
   {<<"nodes">>,<<"screen_name-psych_ic-info">>},
   {r_object,<<"nodes">>,<<"screen_name-psych_ic-info">>,
[{r_content,
  {dict,3,16,16,8,80,48,
   {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
   {{[],[],[],[],[],[],[],[],[],[],
 [[<<"content-type">>,97,112,112,108,105,99,97,
   116,105,111,110,47,106,115,111,110],
  [<<"X-Riak-VTag">>,49,90,120,65,84,100,56,99,48,
   80,86,99,111,122,71,79,108,90,70,97,53,87]],
 [],[],
 [[<<"X-Riak-Last-Modified">>|
   {1317,353201,695471}]],
 [],[]}}},
  <<"{DELETED DATA}">>}],
[{<<2,65,205,48>>,{1,63484572401}}],
{dict,1,16,16,8,80,48,
 {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
 {{[],[],[],[],[],[],[],[],[],[],[],[],[],[],
   [[clean|true]],
   []}}},
undefined},
   1174401,63484572401,
   [{returnbody,true}]}}
** When State == active
**  Data  == {state,94198347718593352149846873983790012612771840,
riak_kv_vnode,

{state,94198347718593352149846873983790012612771840, 
   riak_kv_bitcask_backend,
   {#Ref<0.0.0.3952>,

"/var/lib/riak/bitcask/94198347718593352149846873983790012612771840"},
   {dict,0,16,16,8,80,48,
 {[],[],[],[],[],[],[],[],[],[],[],[],[],
  [],[],[]},
 {{[],[],[],[],[],[],[],[],[],[],[],[],[],
   [],[],[]}}},
   false},
undefined,none,6}
** Reason for termination = 
** {{badmatch,{error,emfile}},
[{bitcask_fileops,create_file_loop,3},
 {bitcask,put,3},
 {riak_kv_bitcask_backend,put,3},
 {riak_kv_vnode,perform_put,3},
 {riak_kv_vnode,do_put,7},
 {riak_kv_vnode,handle_command,3},
 {riak_core_vnode,vnode_command,3},
 {gen_fsm,handle_msg,7}]}



-Original Message-
From: Sean Cribbs [mailto:s...@basho.com]
Sent: Thu 9/29/2011 3:02 PM
To: Jim Adler
Cc: riak-users@lists.basho.com
Subject: Re: Timeout when storing
 
Your environment has too few file handles.  Retry starting riak after
setting `ulimit -n 1024` in the shell.  Also see our wiki page about this
issue: http://wiki.basho.com/Open-Files-Limit.html  You may need to set this
limit specifically for the 'riak' user.

Cheers,

-- 
Sean Cribbs 
Developer Advocate
Basho Technologies, Inc.
http://www.basho.com/

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Timeout when storing

[Jim Adler]

Thanks David. I bumped ERL_MAX_PORTS to 16384 in vm.args, restarted riak, but 
still get the timeout.

Jim

Sent from my phone. Please forgive the typos. 

On Sep 30, 2011, at 9:56 AM, "David Smith"  wrote:

> IIRC, {error, emfile} indicates that the max # of ports (in the erlang
> VM) is being exceeded. Try bumping up ERL_MAX_PORTS in vm.args.
> 
> D.
> 
> On Thu, Sep 29, 2011 at 10:52 PM, Jim Adler  wrote:
>> Thanks Sean.  I added the ulimit -n 10240 to /etc/default/riak, restarted
>> riak, but that didn't work.
>> 
>> Fyodor Yarochkin suggested that the bitcask files could be corrupted, but I
>> wasn't sure which bitcask *.data or *.hint file to delete.  Any pointers?
>> 
>> Here's the /var/log/riak/erlang.log:
>> 
>> =ERROR REPORT 29-Sep-2011::20:27:42 ===
>> ** State machine <0.369.0> terminating
>> ** Last event in was {riak_vnode_req_v1,
>>   94198347718593352149846873983790012612771840,
>>   {fsm,undefined,<0.27704.1>},
>>   {riak_kv_put_req_v1,
>>{<<"nodes">>,<<"screen_name-psych_ic-info">>},
>> 
>> {r_object,<<"nodes">>,<<"screen_name-psych_ic-info">>,
>> [{r_content,
>>   {dict,3,16,16,8,80,48,
>> 
>> {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
>>{{[],[],[],[],[],[],[],[],[],[],
>>  [[<<"content-type">>,97,112,112,108,105,99,97,
>>116,105,111,110,47,106,115,111,110],
>> 
>> [<<"X-Riak-VTag">>,49,90,120,65,84,100,56,99,48,
>>80,86,99,111,122,71,79,108,90,70,97,53,87]],
>>  [],[],
>>  [[<<"X-Riak-Last-Modified">>|
>>{1317,353201,695471}]],
>>  [],[]}}},
>>   <<"{DELETED DATA}">>}],
>> [{<<2,65,205,48>>,{1,63484572401}}],
>> {dict,1,16,16,8,80,48,
>>  {[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
>>  {{[],[],[],[],[],[],[],[],[],[],[],[],[],[],
>>[[clean|true]],
>>[]}}},
>> undefined},
>>1174401,63484572401,
>>[{returnbody,true}]}}
>> ** When State == active
>> **  Data  == {state,94198347718593352149846873983790012612771840,
>> riak_kv_vnode,
>> 
>> {state,94198347718593352149846873983790012612771840,
>>riak_kv_bitcask_backend,
>>{#Ref<0.0.0.3952>,
>> 
>> "/var/lib/riak/bitcask/94198347718593352149846873983790012612771840"},
>>{dict,0,16,16,8,80,48,
>> 
>> {[],[],[],[],[],[],[],[],[],[],[],[],[],
>>   [],[],[]},
>> 
>> {{[],[],[],[],[],[],[],[],[],[],[],[],[],
>>    [],[],[]}}},
>>false},
>> undefined,none,6}
>> ** Reason for termination =
>> ** {{badmatch,{error,emfile}},
>> [{bitcask_fileops,create_file_loop,3},
>>  {bitcask,put,3},
>>  {riak_kv_bitcask_backend,put,3},
>>  {riak_kv_vnode,perform_put,3},
>>  {riak_kv_vnode,do_put,7},
>>  {riak_kv_vnode,handle_command,3},
>>  {riak_core_vnode,vnode_command,3},
>>  {gen_fsm,handle_msg,7}]}
>> 
>> 
>> 
>> -Original Message-
>> From: Sean Cribbs [mailto:s...@basho.com]
>> Sent: Thu 9/29/2011 3:02 PM
>> To: Jim Adler
>> Cc: riak-users@lists.basho.com
>> Subject: Re: Timeout when storing
>> 
>> Your environment has too few file handles.  Retry starting riak after
>> setting `ulimit -n 1024` in the shell.  Also see our wiki page about this
>> issue: http://wiki.basho.com/Open-Files-Limit.html  You may need to set this
>> limit specifically for the 'riak' user.
>> 
>> Cheers,
>> 
>> --
>> Sean Cribbs 
>> Developer Advocate
>> Basho Technologies, Inc.
>> http://www.basho.com/
>> 
>> 
>> ___
>> riak-users mailing list
>> riak-users@lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>> 
>> 
> 
> 
> 
> -- 
> Dave Smith
> Director, Engineering
> Basho Technologies, Inc.
> diz...@basho.com

___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

RE: Timeout when storing

[Jim Adler]

After upgrading my single-node instance to 1.0, I'm still seeing the "timeout 
when storing" issue.  Here are the changes I made based on everyone's 
suggestions (much appreciated!):

- Ubuntu 11.04 (natty) 32-bit
- Python client 1.3.0
- /etc/riak/vm.args: -env ERL_MAX_PORTS 32768
- /etc/default/riak: ulimit -n 32768

Here's the /var/log/crash.log report:

2011-10-01 12:31:03 =ERROR REPORT
** State machine <0.3452.0> terminating 
** Last event in was 
{'riak_vnode_req_v1',1136089163393944065322395631681798128560666312704,{fsm,undefined,<0.3451.0>},{'riak_kv_put_req_v1',{<<"nodes">>,<<"user_id-17527747-info">>},{r_object,<<"nodes">>,<<"user_id-17527747-info">>,[{r_content,{dict,4,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[[<<"content-type">>,97,112,112,108,105,99,97,116,105,111,110,47,106,115,111,110],[<<"X-Riak-VTag">>,49,88,88,75,75,51,90,88,68,117,90,122,85,53,57,85,53,101,107,89,115,110]],[[<<"index">>]],[],[[<<"X-Riak-Last-Modified">>|{1317,497463,847242}]],[],[]}}},<<"{DATA
 
DELETED}">>}],[],{dict,1,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[[clean|true]],[]}}},undefined},51456853,63484716663,[coord]}}
** When State == active
**  Data  == 
{state,1136089163393944065322395631681798128560666312704,riak_kv_vnode,{state,1136089163393944065322395631681798128560666312704,false,riak_kv_bitcask_backend,{state,#Ref<0.0.0.10359>,"1136089163393944065322395631681798128560666312704",[{async_folds,true},[{vnode_vclocks,true},{included_applications,[]},{add_paths,[]},{allow_strfun,false},{storage_backend,riak_kv_bitcask_backend},{legacy_keylisting,false},{reduce_js_vm_count,6},{js_thread_stack,16},{pb_ip,"0.0.0.0"},{riak_kv_stat,true},{map_js_vm_count,8},{mapred_system,pipe},{js_max_vm_mem,8},{pb_port,8087},{legacy_stats,true},{mapred_name,"mapred"},{stats_urlpath,"stats"},{http_url_encoding,on},{hook_js_vm_count,2}],{read_write,true}],1136089163393944065322395631681798128560666312704,"/var/lib/riak/bitcask"},{dict,0,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}}},<<35,9,254,249,78,135,82,106>>,3000,1000,100,100,true,false},undefined,undefined,none,undefined,<0.3454.0>,6}
** Reason for termination = 
** {bad_return_value,{error,{write_locked,emfile}}}
2011-10-01 12:31:03 =CRASH REPORT
  crasher:
initial call: riak_core_vnode:init/1
pid: <0.3452.0>
registered_name: []
exception exit: {bad_return_value,{error,{write_locked,emfile}}}
  in function  gen_fsm:terminate/7
  in call from proc_lib:init_p_do_apply/3
ancestors: [riak_core_vnode_sup,riak_core_sup,<0.92.0>]
messages: [{'EXIT',<0.3454.0>,shutdown}]
links: [<0.96.0>]
dictionary: []
trap_exit: true
status: running
heap_size: 6765
stack_size: 24
reductions: 160650
  neighbours:
2011-10-01 12:31:03 =SUPERVISOR REPORT
 Supervisor: {local,riak_core_vnode_sup}
 Context:child_terminated
 Reason: {bad_return_value,{error,{write_locked,emfile}}}
 Offender:   
[{pid,<0.3452.0>},{name,undefined},{mfargs,{riak_core_vnode,start_link,undefined}},{restart_type,temporary},{shutdown,30},{child_type,worker}]

2011-10-01 12:45:28 =ERROR REPORT
Failed to merge 
"/var/lib/riak/bitcask/605153021707326989568713251046585937826284568576/var/lib/riak/bitcask/605153021707326989568713251046585937826284568576/1315770213.bitcask.data/var/lib/riak/bitcask/605153021707326989568713251046585937826284568576/1316329673.bitcask.data/var/lib/riak/bitcask/605153021707326989568713251046585937826284568576/1316330222.bitcask.data/var/lib/riak/bitcask/605153021707326989568713251046585937826284568576/1316879145.bitcask.data/var/lib/riak/bitcask/605153021707326989568713251046585937826284568576/1316995340.bitcask.data/var/lib/riak/bitcask/605153021707326989568713251046585937826284568576/1317493005.bitcask.data/var/lib/riak/bitcask/605153021707326989568713251046585937826284568576/1317495168.bitcask.data":
 
{{badmatch,{error,emfile}},[{bitcask,'-merge1/3-lc$^0/1-1-',1},{bitcask,'-merge1/3-lc$^0/1-1-',1},{bitcask,'merge1',3},{bitcask_merge_worker,do_merge,1}]}


-Original Message-
From: David Smith [mailto:diz...@basho.com]
Sent: Fri 9/30/2011 9:56 AM
To: Jim Adler
Cc: Sean Cribbs; riak-users@lists.basho.com
Subject: Re: Timeout when storing
 
IIRC, {error, emfile} indicates that the max # of ports (in the erlang
VM) is being exceeded. Try bumping up ERL_MAX_PORTS in vm.args.

D.

On Thu, Sep 29, 2011 

Re: Timeout when storing

[Jim Adler]

Thanks David - I'll try that on my single-node instance, but I'm working 
another Riak issue on another thread. 


Jim 

- Original Message -
From: "David Smith"  
To: "jim adler"  
Sent: Friday, October 7, 2011 7:02:01 AM 
Subject: Re: Timeout when storing 

Hi Jim, 

Sorry for the slow response -- email is like a running battle at times. :) 

How many partitions are you running? 

Also, take down the node and then remove any *.lock files. 

Thanks, 

D. 

On Mon, Oct 3, 2011 at 11:23 AM,  wrote: 
> About 90 out of 3000 are zero-bytes. 
> 
> Jim 
> 
> -Original Message- 
> From: riak-users-boun...@lists.basho.com 
> [mailto:riak-users-boun...@lists.basho.com] On Behalf Of David Smith 
> Sent: Monday, October 03, 2011 4:46 AM 
> To: Jim Adler 
> Cc: riak-users@lists.basho.com 
> Subject: Re: Timeout when storing 
> 
> Jim, 
> 
> If you look at your bitcask directories, do you have a large number of 
> zero-byte files, perchance? 
> 
> D. 
> 
> On Sat, Oct 1, 2011 at 1:58 PM, Jim Adler  wrote: 
>> After upgrading my single-node instance to 1.0, I'm still seeing the 
>> "timeout when storing" issue. Here are the changes I made based on 
>> everyone's suggestions (much appreciated!): 
>> 
>> - Ubuntu 11.04 (natty) 32-bit 
>> - Python client 1.3.0 
>> - /etc/riak/vm.args: -env ERL_MAX_PORTS 32768 
>> - /etc/default/riak: ulimit -n 32768 
>> 
>> Here's the /var/log/crash.log report: 
>> 
>> 2011-10-01 12:31:03 =ERROR REPORT 
>> ** State machine <0.3452.0> terminating 
>> ** Last event in was 
>> {'riak_vnode_req_v1',1136089163393944065322395631681798128560666312704 
>> ,{fsm,undefined,<0.3451.0>},{'riak_kv_put_req_v1',{<<"nodes">>,<<"user 
>> _id-17527747-info">>},{r_object,<<"nodes">>,<<"user_id-17527747-info"> 
>> >,[{r_content,{dict,4,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[], 
>> [],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[[<<"content-type">>,9 
>> 7,112,112,108,105,99,97,116,105,111,110,47,106,115,111,110],[<<"X-Riak 
>> -VTag">>,49,88,88,75,75,51,90,88,68,117,90,122,85,53,57,85,53,101,107, 
>> 89,115,110]],[[<<"index">>]],[],[[<<"X-Riak-Last-Modified">>|{1317,497 
>> 463,847242}]],[],[]}}},<<"{DATA 
>> DELETED}">>}],[],{dict,1,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[], 
>> [],[],[],[],[],[]},{{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[[clean 
>> |true]],[]}}},undefined},51456853,63484716663,[coord]}} 
>> 
>> ** When State == active 
>> ** Data == 
>> {state,1136089163393944065322395631681798128560666312704,riak_kv_vnode 
>> ,{state,1136089163393944065322395631681798128560666312704,false,riak_k 
>> v_bitcask_backend,{state,#Ref<0.0.0.10359>,"11360891633939440653223956 
>> 31681798128560666312704",[{async_folds,true},[{vnode_vclocks,true},{in 
>> cluded_applications,[]},{add_paths,[]},{allow_strfun,false},{storage_b 
>> ackend,riak_kv_bitcask_backend},{legacy_keylisting,false},{reduce_js_v 
>> m_count,6},{js_thread_stack,16},{pb_ip,"0.0.0.0"},{riak_kv_stat,true}, 
>> {map_js_vm_count,8},{mapred_system,pipe},{js_max_vm_mem,8},{pb_port,80 
>> 87},{legacy_stats,true},{mapred_name,"mapred"},{stats_urlpath,"stats"} 
>> ,{http_url_encoding,on},{hook_js_vm_count,2}],{read_write,true}],11360 
>> 89163393944065322395631681798128560666312704,"/var/lib/riak/bitcask"}, 
>> {dict,0,16,16,8,80,48,{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[] 
>> },{{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}}},<<35,9,254,249, 
>> 78,135,82,106>>,3000,1000,100,100,true,false},undefined,undefined,none 
>> ,undefined,<0.3454.0>,6} 
>> ** Reason for termination = 
>> ** {bad_return_value,{error,{write_locked,emfile}}} 
>> 2011-10-01 12:31:03 =CRASH REPORT 
>> crasher: 
>> initial call: riak_core_vnode:init/1 
>> pid: <0.3452.0> 
>> registered_name: [] 
>> exception exit: {bad_return_value,{error,{write_locked,emfile}}} 
>> in function gen_fsm:terminate/7 
>> in call from proc_lib:init_p_do_apply/3 
>> ancestors: [riak_core_vnode_sup,riak_core_sup,<0.92.0>] 
>> messages: [{'EXIT',<0.3454.0>,shutdown}] 
>> links: [<0.96.0>] 
>> dictionary: [] 
>> trap_exit: true 
>> status: running 
>> heap_size: 6765 
>> stack_size: 24 
>> reductions: 160650 
>> n

Re: Riak 1.0 pre2 legacy_keylisting crash

[Jim Adler]

I'm seeing the same behavior and logs on a bucket with about 8M keys. Fyodor, 
any luck with any of Bryan's suggestions? 


Jim 

- Original Message -
From: "Bryan Fink"  
To: "Fyodor Yarochkin"  
Cc: riak-users@lists.basho.com 
Sent: Friday, October 7, 2011 6:06:15 AM 
Subject: Re: Riak 1.0 pre2 legacy_keylisting crash 

On Fri, Oct 7, 2011 at 1:50 AM, Fyodor Yarochkin  wrote: 
> Here's one of the queries that consistently generates series of 
> 'fitting_died' log messages: 
> 
> { 
> "inputs":{ 
> "bucket":"test", 
> "index":"integer_int", 
… 
> }, 
> "query":[ 
> {"map":{"language":"javascript", 
… 
> }, 
> {"reduce":{"language":"javascript", 
… 
> {"reduce":{"language":"javascript", 
… 
> ],"timeout": 9000 
> } 
> 
> produces over hundred of " "Supervisor riak_pipe_vnode_worker_sup had 
> child at module undefined at <0.28835.0> exit with reason fitting_died 
> in context child_terminated" entries in log file and returns 'timeout' 

My interpretation of your report is that 9 seconds is not long enough 
to finish your MapReduce query. I'll explain how I arrived at this 
interpretation: 

The log message you're seeing says that many processes that 
riak_pipe_vnode_worker_sup was monitor exited abnormally. That 
supervisor only monitors Riak Pipe worker processes, the processes 
that do the work for Riak 1.0's MapReduce phases. 

The reason those workers gave for exiting abnormally was 
'fitting_died'. This means that the pipeline they were working for 
closed before they were finished with their work. 

The result your received was 'timeout'. The way timeouts work in 
Riak-Pipe-based MapReduce is that a timer triggers a message at the 
given time, causing a monitoring process to cease waiting for results, 
tear down the pipe, and return a timeout message to your client. 

The "tear down the pipe" step in the timeout process is what causes 
all of those 'fitting_died' message you see. They're normal, and are 
intended to aid in analysis like the above. 

With that behind us, though, the question remains: why isn't 9 seconds 
long enough to finish this query? To figure that out, I'd start from 
the beginning: 

1. Is 9 seconds long enough to just finish the index query (using the 
index API outside of MapReduce)? If not, then the next people to jump 
in with help here will want to know more about the types, sizes, and 
counts of data you have indexed. 

2. Assuming the bare index query finishes fast enough, is 9 seconds 
long enough to get through just the index and map phase (no reduce 
phases)? If not, it's likely that either it takes longer than 9 
seconds to pull every object matching your index query out of KV, or 
that contention for Javascript VMs prohibits the throughput needed. 

2a. Try switching to an Erlang map phase. 
{"language":"erlang","module":"riak_kv_mapreduce","function":"map_object_value","arg":"filter_notfound"}
 
should do exactly what your Javascript function does, without 
contending for a JS VM. 

2b. Try increasing the number of JS VMs available for map phases. In 
your app.config, find the 'map_js_vm_count' setting, and increase it. 

3. Assuming just the map phase also makes it through, is 9 seconds 
long enough to get through just the index, map, and first reduce phase 
(leave off the second)? Your first reduce phase looks like it doesn't 
do anything … is it needed? Try removing it. 

4. If you get all the way to the final phase before hitting the 9 
second timeout, then it's may be that the re-reduce behavior of Riak 
KV's MapReduce causes your function to be too expensive. This will be 
especially true if you expect that phase to receive thousands of 
inputs. A sort function such as yours probably doesn't benefit from 
re-reduce, so I would recommend disabling it by adding 
"arg":{"reduce_phase_only_1":true} to that reduce phase's 
specification. With that in place, your function should be evaluated 
only once, with all the inputs it will receive. This may still fail 
because of the time it can take to encode/decode a large set of 
inputs/outputs to/from JSON, but doing it only once may be enough to 
get you finished. 

Hope that helps, 
Bryan 

___ 
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

RE: Riak 1.0

[Jim Adler]

I tried the Bitcask-to-LevelDB procedure on 1.0.1 to switch my backend from 
Bitcask to LevelDB. I have one node on Bitcask with my data and the other node 
with a fresh LevelDB backend. When I join the fresh LevelDB node, I get the 
following error:  Failed: r...@xx.xx.xx.xx has a different ring_creation_size

 

riak-admin status | grep creation gives:  ring_creation_size : 256

 

Any ideas?

 

Jim

 

From: riak-users-boun...@lists.basho.com 
[mailto:riak-users-boun...@lists.basho.com] On Behalf Of Ian Plosker
Sent: Saturday, October 01, 2011 8:15 AM
To: 54chen
Cc: riak-users
Subject: Re: Riak 1.0

 

There are instructions on the wiki: 
http://wiki.basho.com/Secondary-Indexes.html#Migrating-an-Existing-Cluster-(Method-One)

 

Basically, you will have each node leave the cluster, switch the backend, and 
then rejoin. The process is something like this:

 

1) Issue `riak-admin leave` and wait for all transfers to complete

2) `riak stop`

3) Change the backend to the `riak_kv_eleveldb_backend`

4) `riak start` and `riak-admin join `

5) Repeat for each node in the cluster

 

 

Ian Plosker

Developer Advocate

Basho Technologies

 

 

On Sep 30, 2011, at 10:41 PM, 54chen wrote:





Congratulations!

Can you give me an example of how the 0.14.2（bitcask） upgrade to 1.0（levelDB）?




2011/10/1 Alexander Sicular 

Awesome!

Already got it in place on my mac and ubuntu dev boxes. Smooth.

-Alexander Sicular

@siculars
http://siculars.posterous.com  


On Sep 30, 2011, at 4:31 PM, David Smith wrote:

> Hi All,
>
> I am very pleased to announce that Riak 1.0 is tagged and officially
> ready for downloading.
>
> Pre-built installations and source tarballs are available at:
>
> http://downloads.basho.com/riak/CURRENT
>
> Release notes are here:
>
> https://github.com/basho/riak/blob/1.0/RELEASE-NOTES.org
>
> There is also a blog post about the release here:
>
> http://blog.basho.com/2011/09/30/Riak-1-dot-0-is-Official/
>
> 1.0 has been two years and 15 releases in the making. Thank you all
> for being a part of this project and wonderful community. We couldn't
> have done it without you.
>
> Sincerely,
>
> D.
>
> --
> Dave Smith
> Director, Engineering
> Basho Technologies, Inc.
> diz...@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




-- 
-
http://www.54chen.com   
http://twitter.com/54chen
___
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

Re: Riak 1.0

[Jim Adler]

For the bitcask backend, ring_num_partitions=64 and ring_creation_size=256.
I haven't seen where to set ring_num_partitions in app.config.  I have about
8 million keys stored in this cluster.

So, how do I bring up a LevelDB node and join to the existing cluster given
this 64/256 partitions/creation_size config?

Thanks for the help!

Jim

From:  Dan Reverri 
Date:  Fri, 21 Oct 2011 09:41:02 -0700
To:  Jim Adler 
Cc:  Ian Plosker , "riak-users@lists.basho.com"

Subject:  Re: Riak 1.0

The "ring_creation_size" parameter in app.config must be set before the node
has been started and written a ring file. Assuming the LevelDB node is
empty, you can do the following:

1. Stop the node
2. Clear out the data directories (data/ring, data/leveldb, data/bitcask,
data/mr_queue, data/kv_vnode)
3. Verify "ring_creation_size" is set to 256 in the app.config file
4. Start the node
5. Verify "ring_num_partitions" in "riak-admin status" is 256
6. Join the node to the cluster

Thanks,
Dan
 
Daniel Reverri
Developer Advocate
Basho Technologies, Inc.
d...@basho.com


On Fri, Oct 21, 2011 at 9:30 AM,   wrote:
> 64 on the LevelDB vs 256 on the Bitcask.  I guess that’s it.   Workaround?
>  
> Thanks,
> Jim
>  
> From: Dan Reverri [mailto:d...@basho.com]
> Sent: Friday, October 21, 2011 9:27 AM
> To: Jim Adler
> Cc: Ian Plosker; riak-users
> Subject: Re: Riak 1.0
> 
>  
> Hi Jim,
> 
>  
> 
> Can you check "ring_num_partitions" on each node from "riak-admin status"?
> 
>  
> 
> Thanks,
> Dan
> 
> 
> Daniel Reverri
> Developer Advocate
> Basho Technologies, Inc.
> d...@basho.com
> 
> 2011/10/20 Jim Adler 
> 
> I tried the Bitcask-to-LevelDB procedure on 1.0.1 to switch my backend from
> Bitcask to LevelDB. I have one node on Bitcask with my data and the other node
> with a fresh LevelDB backend. When I join the fresh LevelDB node, I get the
> following error:  Failed: r...@xx.xx.xx.xx has a different ring_creation_size
>  
> riak-admin status | grep creation gives:  ring_creation_size : 256
>  
> Any ideas?
>  
> Jim
>  
> 
> From: riak-users-boun...@lists.basho.com
> [mailto:riak-users-boun...@lists.basho.com] On Behalf Of Ian Plosker
> Sent: Saturday, October 01, 2011 8:15 AM
> To: 54chen
> ! Cc: riak-users
> Subject: Re: Riak 1.0
> 
>  
> 
> There are instructions on the wiki:
> http://wiki.basho.com/Secondary-Indexes.html#Migrating-an-Existing-Cluster-(Me
> thod-One)
> 
>  
> 
> Basically, you will have each node leave the cluster, switch the backend, and
> then rejoin. The process is something like this:
> 
>  
> 
> 1) Issue `riak-admin leave` and wait for all transfers to complete
> 
> 2) `riak stop`
> 
> 3) Change the backend to the `riak_kv_eleveldb_backend`
> 
> 4) `riak start` and `riak-admin join `
> 
> 5) Repeat for each node in the cluster
> 
>  
> 
>  
> 
> Ian Plosker
> 
> Developer Advocate
> 
> Basho Technologies
>  
>  
> 
> On Sep 30, 2011, at 10:41 PM, 54chen wrote:
>  
> Congratulations!
> 
> Can you give me an example of how the 0.14.2（bitcas! k） upgrade to 1.0（
> levelDB）?
> 
> 2011/10/1 Alexander Sicular 
> Awesome!
> 
> Already got it in place on my mac and ubuntu dev boxes. Smooth.
> 
> -Alexander Sicular
> 
> @siculars
> http://siculars.posterous.com <http://siculars.posterous.com/>
> 
> 
> On Sep 30, 2011, at 4:31 PM, David Smith wrote:
> 
>> > Hi All,
>> >
>> > I am very pleased to announce that Riak 1.0 is tagged and officially
>> > ready for downloading.
>> >
>> > Pre-built installations and source tarballs are available at:
>> >
>> > http://downloads.basho.com/riak/CURRENT
>> >
>> > Release notes are here:
>> >
>> > https://github.com/basho/riak/blob/1.0/RELEASE-NOTES.org
>> <https://github.com/basho/riak/blob/1.0/RELE!%20ASE-NOTES.org>
>> >
>> > There is also a blog post about the release here:
>> >
>> > http://blog.basho.com/2011/09/30/Riak-1-dot-0-is-Official/
>> >
>> > 1.0 has been two years and 15 releases in the making. Thank you all
>> > for being a part of this project and wonderful community. We couldn't
>> > have done it without you.
>> >
>> > Sincerely,
>> >
>> > D.
>> >
>> > --
>> > Dave Smith
>> > Director, Engineering
>> > Basho Technologies, Inc.
>> > diz...@basho.com
>> >
>> > ___
>> > riak-users mailing list
>> > riak-users@lists.b

Re: Riak 1.0

[Jim Adler]

Thanks Nico.  I'll make the changes you suggest to regain the consistency.
My understanding is a ring size of 64 would limit my cluster to about 6
nodes, right?

Jim

From:  Nico Meyer 
Date:  Sat, 22 Oct 2011 12:12:13 +0200
To:  "riak-users@lists.basho.com" , Jim Adler

Subject:  Re: Riak 1.0


 Hello Jim,
 
 it sounds like the ring_creation_size in your app.conf file is inconsistent
with the actual ring size on your existing nodes. This would happen, if the
ring_creation_size in the config was changed after the ring as been created.
As the name implies, the setting is only used when starting a fresh/empty
node for the first time, so changing it afterwards has no real effect, other
than showing up in the riak-admin output and severly confusing people ;-).
 
 So to fix your problem, first of all, since the real ring size is 64, your
new node must also have a ring size of 64. So do as Dan suggested, but set
the ring_creation_size to 64 instead of 256.
 At that point joining might already work. I checked the code, and if the
new gossip protocol is used, riak checks for equality the actual ring sizes
of the two nodes to join. But if the legacy gossip protocol is still used,
riak compares the ring_creation_size config settings of both nodes.
 
 In any case, you should change the ring_creation_size on all your nodes to
64 and restart them, if only to make thing consistent again.
 
 Cheers,
 Nico
 
 Am 22.10.2011 09:46, schrieb Jim Adler:
>  
> For the bitcask backend, ring_num_partitions=64 and ring_creation_size=256. I
> haven't seen where to set ring_num_partitions in app.config.  I have about 8
> million keys stored in this cluster.
>  
> 
>  
>  
> So, how do I bring up a LevelDB node and join to the existing cluster given
> this 64/256 partitions/creation_size config?
>  
> 
>  
>  
> Thanks for the help!
>  
> 
>  
>  
> Jim
>  
> 
>  
>   
> From:  Dan Reverri 
>  Date:  Fri, 21 Oct 2011 09:41:02 -0700
>  To:  Jim Adler 
>  Cc:  Ian Plosker , "riak-users@lists.basho.com"
> 
>  Subject:  Re: Riak 1.0
>  
>  
> 
>  
>  The "ring_creation_size" parameter in app.config must be set before the node
> has been started and written a ring file. Assuming the LevelDB node is empty,
> you can do the following:
> 
>  
>  
> 1. Stop the node
>  
> 2. Clear out the data directories (data/ring, data/leveldb, data/bitcask,
> data/mr_queue, data/kv_vnode)
>  
> 3. Verify "ring_creation_size" is set to 256 in the app.config file
>  
> 4. Start the node
>  
> 5. Verify "ring_num_partitions" in "riak-admin status" is 256
>  
> 6. Join the node to the cluster
>  
> 
>  
>  
> Thanks,
>  
> Dan 
>  
>  Daniel Reverri
>  Developer Advocate
>  Basho Technologies, Inc.
>  d...@basho.com
>  
>  
>  
> On Fri, Oct 21, 2011 at 9:30 AM,  wrote:
>  
>>  
>>  
>>  
>> 
>> 64 on the LevelDB vs 256 on the Bitcask.  I guess that’s it.   Workaround?
>>  
>>  
>>  
>> Thanks,
>>  
>> Jim
>>  
>>  
>>  
>> From: Dan Reverri [mailto:d...@basho.com]
>>  Sent: Friday, October 21, 2011 9:27 AM
>>  To: Jim Adler
>>  Cc: Ian Plosker; riak-users
>>  Subject: Re: Riak 1.0
>>  
>>  
>>  
>> 
>>  
>>  
>> Hi Jim,
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>> 
>> Can you check "ring_num_partitions" on each node from "riak-admin status"?
>>  
>>  
>>  
>> 
>>  
>>  
>>  
>>  
>> 
>> Thanks,
>>  Dan
>>  
>>  
>>  
>> 
>> 
>>  Daniel Reverri
>>  Developer Advocate
>>  Basho Technologies, Inc.
>>  d...@basho.com
>>  
>>  
>>  
>>  
>> 
>> 2011/10/20 Jim Adler 
>>  
>>  
>>  
>> 
>> I tried the Bitcask-to-LevelDB procedure on 1.0.1 to switch my backend from
>> Bitcask to LevelDB. I have one node on Bitcask with my data and the other
>> node with a fresh LevelDB backend. When I join the fresh LevelDB node, I get
>> the following error:  Failed: r...@xx.xx.xx.xx has a different
>> ring_creation_size
>>  
>>  
>>  
>> riak-admin status | grep creation gives:  ring_creation_size : 256
>>  
>>  
>>  
>> Any ideas?
>>  
>>  
>>  
>> Jim
>>  
>>  
>>  
>>  
>>  
>> 
>> From: riak-users-boun...@lists.basho.com
>> [mailto:riak-users-boun...@lists.basho.com] On Behalf Of Ian Plosker
>>  Sent: Saturday, October 01, 2011 8:15 AM
>>  To: 54c

Re: Riak 1.0

[Jim Adler]

So, for the benefit of the list, here was my bonehead move: 

My installation script automatically 'riak starts' which, of course, uses the 
default app.config ring_creation_size of 64 before I get a chance to change it. 
Hello tarpit.

Lesson: don't 'riak start' on a fresh node until you modify app.config 
ring_creation_size.

Jim

On Oct 22, 2011, at 3:12 AM, Nico Meyer  wrote:

> Hello Jim,
> 
> it sounds like the ring_creation_size in your app.conf file is inconsistent 
> with the actual ring size on your existing nodes. This would happen, if the 
> ring_creation_size in the config was changed after the ring as been created. 
> As the name implies, the setting is only used when starting a fresh/empty 
> node for the first time, so changing it afterwards has no real effect, other 
> than showing up in the riak-admin output and severly confusing people ;-).
> 
> So to fix your problem, first of all, since the real ring size is 64, your 
> new node must also have a ring size of 64. So do as Dan suggested, but set 
> the ring_creation_size to 64 instead of 256.
> At that point joining might already work. I checked the code, and if the new 
> gossip protocol is used, riak checks for equality the actual ring sizes 
> of the two nodes to join. But if the legacy gossip protocol is still used, 
> riak compares the ring_creation_size config settings of both nodes.
> 
> In any case, you should change the ring_creation_size on all your nodes 
> to 64 and restart them, if only to make thing consistent again.
> 
> Cheers,
> Nico
> 
> Am 22.10.2011 09:46, schrieb Jim Adler:
>> 
>> For the bitcask backend, ring_num_partitions=64 and ring_creation_size=256. 
>> I haven't seen where to set ring_num_partitions in app.config.  I have about 
>> 8 million keys stored in this cluster.
>> 
>> So, how do I bring up a LevelDB node and join to the existing cluster given 
>> this 64/256 partitions/creation_size config?
>> 
>> Thanks for the help!
>> 
>> Jim
>> 
>> From: Dan Reverri 
>> Date: Fri, 21 Oct 2011 09:41:02 -0700
>> To: Jim Adler 
>> Cc: Ian Plosker , "riak-users@lists.basho.com" 
>> 
>> Subject: Re: Riak 1.0
>> 
>> The "ring_creation_size" parameter in app.config must be set before the node 
>> has been started and written a ring file. Assuming the LevelDB node is 
>> empty, you can do the following:
>> 
>> 1. Stop the node
>> 2. Clear out the data directories (data/ring, data/leveldb, data/bitcask, 
>> data/mr_queue, data/kv_vnode)
>> 3. Verify "ring_creation_size" is set to 256 in the app.config file
>> 4. Start the node
>> 5. Verify "ring_num_partitions" in "riak-admin status" is 256
>> 6. Join the node to the cluster
>> 
>> Thanks,
>> Dan
>>  
>> Daniel Reverri
>> Developer Advocate
>> Basho Technologies, Inc.
>> d...@basho.com
>> 
>> 
>> On Fri, Oct 21, 2011 at 9:30 AM,  wrote:
>> 64 on the LevelDB vs 256 on the Bitcask.  I guess that’s it.   Workaround?
>> 
>>  
>> 
>> Thanks,
>> 
>> Jim
>> 
>>  
>> 
>> From: Dan Reverri [mailto:d...@basho.com] 
>> Sent: Friday, October 21, 2011 9:27 AM
>> To: Jim Adler
>> Cc: Ian Plosker; riak-users
>> Subject: Re: Riak 1.0
>> 
>>  
>> 
>> Hi Jim,
>> 
>>  
>> 
>> Can you check "ring_num_partitions" on each node from "riak-admin status"?
>> 
>>  
>> 
>> Thanks,
>> Dan
>> 
>> 
>> Daniel Reverri
>> Developer Advocate
>> Basho Technologies, Inc.
>> d...@basho.com
>> 
>> 2011/10/20 Jim Adler 
>> 
>> I tried the Bitcask-to-LevelDB procedure on 1.0.1 to switch my backend from 
>> Bitcask to LevelDB. I have one node on Bitcask with my data and the other 
>> node with a fresh LevelDB backend. When I join the fresh LevelDB node, I get 
>> the following error:  Failed: r...@xx.xx.xx.xx has a different 
>> ring_creation_size
>> 
>>  
>> 
>> riak-admin status | grep creation gives:  ring_creation_size : 256
>> 
>>  
>> 
>> Any ideas?
>> 
>>  
>> 
>> Jim
>> 
>>  
>> 
>> From: riak-users-boun...@lists.basho.com 
>> [mailto:riak-users-boun...@lists.basho.com] On Behalf Of Ian Plosker
>> Sent: Saturday, October 01, 2011 8:15 AM
>> To: 54chen
>> ! Cc: riak-users
>> Subject: Re: Riak 1.0
>> 
>>  
>> 
>> There are instructions on the wiki: 
>> http://wiki.basho.com/Se

Key Filter Timeout

[Jim Adler]

I'm trying to run a very simplified key filter that's timing out.  I've got
about 8M keys in a 3-node cluster, 15 GB memory, num_partitions=256, LevelDB
backend.

I'm thinking this should be pretty quick. What am I doing wrong?

Jim

Here's the query:

curl -v -d 
'{"inputs":{"bucket":"nodes","key_filters":[["eq","user_id-xxx-info"]]},
"query":[{"reduce":{"language":"erlang","module":"riak_kv_mapreduce","functi
on":"reduce_identity"}}]}' -H "Content-Type: application/json"
http://xx.xx.xx.xx:8098/mapred

Here's the log:

18:25:08.892 [error] gen_fsm <0.20795.0> in state executing terminated with
reason: {error,flow_timeout}
18:25:08.961 [error] CRASH REPORT Process <0.20795.0> with 2 neighbours
crashed with reason: {error,flow_timeout}
18:25:08.963 [error] Supervisor luke_flow_sup had child undefined started
with {luke_flow,start_link,undefined} at <0.20795.0> exit with reason
{error,flow_timeout} in context child_terminated
18:25:08.966 [error] gen_fsm <0.20798.0> in state waiting_kl terminated with
reason: {error,flow_timeout}
18:25:08.971 [error] CRASH REPORT Process <0.20798.0> with 0 neighbours
crashed with reason: {error,flow_timeout}
18:25:08.980 [error] Supervisor riak_kv_keys_fsm_legacy_sup had child
undefined started with {riak_kv_keys_fsm_legacy,start_link,undefined} at
<0.20798.0> exit with reason {error,flow_timeout} in context
child_terminated
18:25:08.983 [error] Supervisor luke_phase_sup had child undefined started
with {luke_phase,start_link,undefined} at <0.20797.0> exit with reason
{error,flow_timeout} in context child_terminated
18:25:08.996 [error] Supervisor luke_phase_sup had child undefined started
with {luke_phase,start_link,undefined} at <0.20796.0> exit with reason
{error,flow_timeout} in context child_terminated




___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Key Filter Timeout

[Jim Adler]

I will be loosening the key filter criterion after I get the basics working,
which I thought would be a simple equality check. 8M keys isn't really a
large data set, is it?  I thought that keys were stored in memory and key
filters just operated on those memory keys and not data.

Jim

From:  Ryan Caught 
Date:  Sun, 23 Oct 2011 14:52:48 -0400
To:  Jim Adler 
Cc:  "riak-users@lists.basho.com" 
Subject:  Re: Key Filter Timeout

If you are doing just a simple equality check in the key filter, then why
not skip key filters and lookup the key directly?  Key filters are not
performant over large data sets.

On Sun, Oct 23, 2011 at 2:38 PM, Jim Adler  wrote:
> I'm trying to run a very simplified key filter that's timing out.  I've got
> about 8M keys in a 3-node cluster, 15 GB memory, num_partitions=256, LevelDB
> backend.
> 
> I'm thinking this should be pretty quick. What am I doing wrong?
> 
> Jim
> 
> Here's the query:
> 
> curl -v -d 
> '{"inputs":{"bucket":"nodes","key_filters":[["eq","user_id-xxx-info"]]},"q
> uery":[{"reduce":{"language":"erlang","module":"riak_kv_mapreduce","function":
> "reduce_identity"}}]}' -H "Content-Type: application/json"
> http://xx.xx.xx.xx:8098/mapred
> 
> Here's the log:
> 
> 18:25:08.892 [error] gen_fsm <0.20795.0> in state executing terminated with
> reason: {error,flow_timeout}
> 18:25:08.961 [error] CRASH REPORT Process <0.20795.0> with 2 neighbours
> crashed with reason: {error,flow_timeout}
> 18:25:08.963 [error] Supervisor luke_flow_sup had child undefined started with
> {luke_flow,start_link,undefined} at <0.20795.0> exit with reason
> {error,flow_timeout} in context child_terminated
> 18:25:08.966 [error] gen_fsm <0.20798.0> in state waiting_kl terminated with
> reason: {error,flow_timeout}
> 18:25:08.971 [error] CRASH REPORT Process <0.20798.0> with 0 neighbours
> crashed with reason: {error,flow_timeout}
> 18:25:08.980 [error] Supervisor riak_kv_keys_fsm_legacy_sup had child
> undefined started with {riak_kv_keys_fsm_legacy,start_link,undefined} at
> <0.20798.0> exit with reason {error,flow_timeout} in context child_terminated
> 18:25:08.983 [error] Supervisor luke_phase_sup had child undefined started
> with {luke_phase,start_link,undefined} at <0.20797.0> exit with reason
> {error,flow_timeout} in context child_terminated
> 18:25:08.996 [error] Supervisor luke_phase_sup had child undefined started
> with {luke_phase,start_link,undefined} at <0.20796.0> exit with reason
> {error,flow_timeout} in context child_terminated
> 
> 
> 
> ___
> 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

Re: Key Filter Timeout

[Jim Adler]

Thanks Kelly.  You were spot-on.  I had upgraded app.config on my other two
nodes but had missed one.

So, I updated app.config, restarted all cluster nodes, and reran the same
query.  It now looks like a pipe error:

22:56:37.697 [error] Supervisor riak_pipe_builder_sup had child undefined
started with {riak_pipe_builder,start_link,undefined} at <0.449.0> exit with
reason killed in context child_terminated
22:56:37.701 [error] Supervisor riak_pipe_fitting_sup had child undefined
started with {riak_pipe_fitting,start_link,undefined} at <0.450.0> exit with
reason killed in context child_terminated
22:56:37.703 [error] gen_fsm <0.452.0> in state wait_pipeline_shutdown
terminated with reason: {sink_died,killed}
22:56:37.705 [error] CRASH REPORT Process <0.452.0> with 1 neighbours
crashed with reason: {sink_died,killed}
22:56:37.711 [error] Supervisor riak_pipe_fitting_sup had child undefined
started with {riak_pipe_fitting,start_link,undefined} at <0.453.0> exit with
reason {sink_died,killed} in context child_terminated
22:56:37.712 [error] Supervisor riak_pipe_builder_sup had child undefined
started with {riak_pipe_builder,start_link,undefined} at <0.452.0> exit with
reason {sink_died,killed} in context child_terminated

Ideas?

Jim

From:  Kelly McLaughlin 
Date:  Sun, 23 Oct 2011 14:13:09 -0600
To:  Jim Adler 
Cc:  "riak-users@lists.basho.com" 
Subject:  Re: Key Filter Timeout

Jim,

Looks like you are possibly using both the legacy key listing option and the
legacy map reduce. Assuming all your nodes are on Riak 1.0, check your
app.config files on all nodes and make sure mapred_system is set to pipe and
legacy_keylisting is set to false. If that's not already the case you should
see better performance. If you are still getting the same or similar errors
with those setting in place, please respond with what they are so we can
look into it more. Thanks.

Kelly

On Oct 23, 2011, at 12:38 PM, Jim Adler wrote:

> I'm trying to run a very simplified key filter that's timing out.  I've got
> about 8M keys in a 3-node cluster, 15 GB memory, num_partitions=256, LevelDB
> backend.
> 
> I'm thinking this should be pretty quick. What am I doing wrong?
> 
> Jim
> 
> Here's the query:
> 
> curl -v -d 
> '{"inputs":{"bucket":"nodes","key_filters":[["eq","user_id-xxx-info"]]},"q
> uery":[{"reduce":{"language":"erlang","module":"riak_kv_mapreduce","function":
> "reduce_identity"}}]}' -H "Content-Type: application/json"
> http://xx.xx.xx.xx:8098/mapred
> 
> Here's the log:
> 
> 18:25:08.892 [error] gen_fsm <0.20795.0> in state executing terminated with
> reason: {error,flow_timeout}
> 18:25:08.961 [error] CRASH REPORT Process <0.20795.0> with 2 neighbours
> crashed with reason: {error,flow_timeout}
> 18:25:08.963 [error] Supervisor luke_flow_sup had child undefined started with
> {luke_flow,start_link,undefined} at <0.20795.0> exit with reason
> {error,flow_timeout} in context child_terminated
> 18:25:08.966 [error] gen_fsm <0.20798.0> in state waiting_kl terminated with
> reason: {error,flow_timeout}
> 18:25:08.971 [error] CRASH REPORT Process <0.20798.0> with 0 neighbours
> crashed with reason: {error,flow_timeout}
> 18:25:08.980 [error] Supervisor riak_kv_keys_fsm_legacy_sup had child
> undefined started with {riak_kv_keys_fsm_legacy,start_link,undefined} at
> <0.20798.0> exit with reason {error,flow_timeout} in context child_terminated
> 18:25:08.983 [error] Supervisor luke_phase_sup had child undefined started
> with {luke_phase,start_link,undefined} at <0.20797.0> exit with reason
> {error,flow_timeout} in context child_terminated
> 18:25:08.996 [error] Supervisor luke_phase_sup had child undefined started
> with {luke_phase,start_link,undefined} at <0.20796.0> exit with reason
> {error,flow_timeout} in context child_terminated
> 
> 
> ___
> 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

Re: Key Filter Timeout

[Jim Adler]

A little context on my use-case here.  I've got about 8M keys in this 3 node
cluster.  I need to clean out some bad keys and some bad data.  So, I'm
using the key filter and search functionality to accomplish this (I tend to
use the riak python client).  But, to be honest, I'm having a helluva time
getting these basic tasks accomplished before I ramp to hundreds of millions
of keys.

Thanks for any help.

Jim

From:  Kelly McLaughlin 
Date:  Sun, 23 Oct 2011 14:13:09 -0600
To:  Jim Adler 
Cc:  "riak-users@lists.basho.com" 
Subject:  Re: Key Filter Timeout

Jim,

Looks like you are possibly using both the legacy key listing option and the
legacy map reduce. Assuming all your nodes are on Riak 1.0, check your
app.config files on all nodes and make sure mapred_system is set to pipe and
legacy_keylisting is set to false. If that's not already the case you should
see better performance. If you are still getting the same or similar errors
with those setting in place, please respond with what they are so we can
look into it more. Thanks.

Kelly

On Oct 23, 2011, at 12:38 PM, Jim Adler wrote:

> I'm trying to run a very simplified key filter that's timing out.  I've got
> about 8M keys in a 3-node cluster, 15 GB memory, num_partitions=256, LevelDB
> backend.
> 
> I'm thinking this should be pretty quick. What am I doing wrong?
> 
> Jim
> 
> Here's the query:
> 
> curl -v -d 
> '{"inputs":{"bucket":"nodes","key_filters":[["eq","user_id-xxx-info"]]},"q
> uery":[{"reduce":{"language":"erlang","module":"riak_kv_mapreduce","function":
> "reduce_identity"}}]}' -H "Content-Type: application/json"
> http://xx.xx.xx.xx:8098/mapred
> 
> Here's the log:
> 
> 18:25:08.892 [error] gen_fsm <0.20795.0> in state executing terminated with
> reason: {error,flow_timeout}
> 18:25:08.961 [error] CRASH REPORT Process <0.20795.0> with 2 neighbours
> crashed with reason: {error,flow_timeout}
> 18:25:08.963 [error] Supervisor luke_flow_sup had child undefined started with
> {luke_flow,start_link,undefined} at <0.20795.0> exit with reason
> {error,flow_timeout} in context child_terminated
> 18:25:08.966 [error] gen_fsm <0.20798.0> in state waiting_kl terminated with
> reason: {error,flow_timeout}
> 18:25:08.971 [error] CRASH REPORT Process <0.20798.0> with 0 neighbours
> crashed with reason: {error,flow_timeout}
> 18:25:08.980 [error] Supervisor riak_kv_keys_fsm_legacy_sup had child
> undefined started with {riak_kv_keys_fsm_legacy,start_link,undefined} at
> <0.20798.0> exit with reason {error,flow_timeout} in context child_terminated
> 18:25:08.983 [error] Supervisor luke_phase_sup had child undefined started
> with {luke_phase,start_link,undefined} at <0.20797.0> exit with reason
> {error,flow_timeout} in context child_terminated
> 18:25:08.996 [error] Supervisor luke_phase_sup had child undefined started
> with {luke_phase,start_link,undefined} at <0.20796.0> exit with reason
> {error,flow_timeout} in context child_terminated
> 
> 
> ___
> 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

Re: Key Filter Timeout

[Jim Adler]

Thanks Kelly. Much appreciated! I'll try your suggestions and get back.

Jim

From:  Kelly McLaughlin 
Date:  Sun, 23 Oct 2011 22:02:52 -0600
To:  Jim Adler 
Cc:  "riak-users@lists.basho.com" 
Subject:  Re: Key Filter Timeout

Jim,

A couple of things to note. First, bitcask stores all keys in memory, but
eleveldb does not necessarliy, so the performance of your disks could be a
factor. Not saying it is, but just a difference to be aware of between
bitcask and eleveldb.

Second, the latest error you shared was a timeout from the mapreduce
operation. You can increase the timeout for the operation by modifying your
original query like this:

curl -v -d 
'{"inputs":{"bucket":"nodes","key_filters":[["eq","user_id-xxx-info"]]},
"query":[{"reduce":{"language":"erlang","module":"riak_kv_mapreduce","functi
on":"reduce_identity"}}], "timeout", 120}' -H "Content-Type:
application/json" http://xx.xx.xx.xx:8098/mapred

Finally, you're using a reduce phase in the query when I think you might be
better served by a map phase which will allow you to get more
parallelization during the query execution. Try using a map phase with the
map_identity function instead of reduce_identity and I suspect you will get
better results. Hope that helps and please respond if you have any further
questions or problems. Cheers.

Kelly


On Oct 23, 2011, at 5:40 PM, Jim Adler wrote:

> A little context on my use-case here.  I've got about 8M keys in this 3 node
> cluster.  I need to clean out some bad keys and some bad data.  So, I'm using
> the key filter and search functionality to accomplish this (I tend to use the
> riak python client).  But, to be honest, I'm having a helluva time getting
> these basic tasks accomplished before I ramp to hundreds of millions of keys.
> 
> Thanks for any help.
> 
> Jim
> 
> From:  Kelly McLaughlin 
> Date:  Sun, 23 Oct 2011 14:13:09 -0600
> To:  Jim Adler 
> Cc:  "riak-users@lists.basho.com" 
> Subject:  Re: Key Filter Timeout
> 
> Jim,
> 
> Looks like you are possibly using both the legacy key listing option and the
> legacy map reduce. Assuming all your nodes are on Riak 1.0, check your
> app.config files on all nodes and make sure mapred_system is set to pipe and
> legacy_keylisting is set to false. If that's not already the case you should
> see better performance. If you are still getting the same or similar errors
> with those setting in place, please respond with what they are so we can look
> into it more. Thanks.
> 
> Kelly
> 
> On Oct 23, 2011, at 12:38 PM, Jim Adler wrote:
> 
>> I'm trying to run a very simplified key filter that's timing out.  I've got
>> about 8M keys in a 3-node cluster, 15 GB memory, num_partitions=256, LevelDB
>> backend.
>> 
>> I'm thinking this should be pretty quick. What am I doing wrong?
>> 
>> Jim
>> 
>> Here's the query:
>> 
>> curl -v -d 
>> '{"inputs":{"bucket":"nodes","key_filters":[["eq","user_id-xxx-info"]]},"
>> query":[{"reduce":{"language":"erlang","module":"riak_kv_mapreduce","function
>> ":"reduce_identity"}}]}' -H "Content-Type: application/json"
>> http://xx.xx.xx.xx:8098/mapred
>> 
>> Here's the log:
>> 
>> 18:25:08.892 [error] gen_fsm <0.20795.0> in state executing terminated with
>> reason: {error,flow_timeout}
>> 18:25:08.961 [error] CRASH REPORT Process <0.20795.0> with 2 neighbours
>> crashed with reason: {error,flow_timeout}
>> 18:25:08.963 [error] Supervisor luke_flow_sup had child undefined started
>> with {luke_flow,start_link,undefined} at <0.20795.0> exit with reason
>> {error,flow_timeout} in context child_terminated
>> 18:25:08.966 [error] gen_fsm <0.20798.0> in state waiting_kl terminated with
>> reason: {error,flow_timeout}
>> 18:25:08.971 [error] CRASH REPORT Process <0.20798.0> with 0 neighbours
>> crashed with reason: {error,flow_timeout}
>> 18:25:08.980 [error] Supervisor riak_kv_keys_fsm_legacy_sup had child
>> undefined started with {riak_kv_keys_fsm_legacy,start_link,undefined} at
>> <0.20798.0> exit with reason {error,flow_timeout} in context child_terminated
>> 18:25:08.983 [error] Supervisor luke_phase_sup had child undefined started
>> with {luke_phase,start_link,undefined} at <0.20797.0> exit with reason
>> {error,flow_timeout} in context child_terminated
>> 18:25:08.996 [error] Supervisor luke_phase_sup had child undefined started
>> with {luke_phase,start_link,undefined} at <0.20796.0> exit with reason
>> {error,flow_timeout} in context child_terminated
>> 
>> 
>> ___
>> 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

Re: Key Filter Timeout

[Jim Adler]

Yes, using 1.0.1 with LevelDB. I moved to it from Bitcask in the hopes of 
better performance.

Good to hear about your 60M key use-case. Can you share any key access 
performance numbers?

Jim

On Oct 24, 2011, at 7:23 AM, Mark Steele  wrote:

> Just curious Kyle, you using the 1.0 series?
> 
> I've done some informal testing on a 3 node 1.0 cluster and key listing was 
> working just peachy on 60 million keys using bitcask as the backend.
> 
> Cheers,
> 
> Mark
> 
> On Sunday 23 October 2011 12:26:35 Aphyr wrote:
>> On 10/23/2011 12:11 PM, Jim Adler wrote:
>>> I will be loosening the key filter criterion after I get the basics
>>> working, which I thought would be a simple equality check. 8M keys
>>> isn't really a large data set, is it? I thought that keys were stored
>>> in memory and key filters just operated on those memory keys and not
>>> data.
>>> 
>>> Jim
>> 
>> That's about where we started seeing timeouts in list-keys. Around 25
>> million keys, list-keys started to take down the cluster. (6 nodes, 1024
>> partitions). You may not encounter these problems, but were I in your
>> position and planning to grow... I would prepare to stop using key
>> filters, bucket listing, and key listing early.
>> 
>> Our current strategy is to store the keys in Redis, and synchronize them
>> with post-commit hooks and a process that reads over bitcask. With
>> ionice 3, it's fairly low-impact. https://github.com/aphyr/bitcask-ruby
>> may be useful.
>> 
>> --Kyle
>> 
>>   # Simplified code, extracted from our bitcask scanner:
>>   def run
>> `renice 10 #{Process.pid}`
>> `ionice -c 3 -p #{Process.pid}`
>> 
>>   begin
>> bitcasks_dir = '/var/lib/riak/bitcask'
>> dirs = Dir.entries(bitcasks_dir).select do |dir|
>>   dir =~ /^\d+$/
>> end.map do |dir|
>>   File.join(bitcasks_dir, dir)
>> end
>> 
>> dirs.each do |dir|
>>   scan dir
>>   GC.start
>> end
>> log.info "Completed run"
>>   rescue => e
>> log.error "#{e}\n#{e.backtrace.join "\n"}"
>> sleep 10
>>   end
>> end
>>   end
>> 
>>   def scan(dir)
>> log.info "Loading #{dir}"
>> b = Bitcask.new dir
>> b.load
>> 
>> log.info "Updating #{dir}"
>> b.keydir.each do |key, e|
>>   bucket, key = BERT.decode(key).map { |x|
>> Rack::Utils.unescape x
>>   }
>>   # Handle determines what to do with this particular bucket/key
>>   # combo; e.g. insert into redis.
>>   handle bucket, key, e
>> end
>>   end
>> 
>> ___
>> 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

Re: Key Filter Timeout

[Jim Adler]

Great validation. Thanks Mark.

Jim

On 10/24/11 7:51 AM, "Mark Steele"  wrote:

>It was a pretty simple benchmark test using a custom built protocol
>buffer client, so I wouldn't put too much faith in it.
>
>As far as performance, my client was able to retrieve keys at a rate of
>about 120 thousand keys per second from the key listing operation. The
>key listing performance was constant, my testing went from 1 million keys
>stored to 60 million with very little variation in throughput.
>
>I guess the mantra is: Test test test test with your app, YMMV
>
>Cheers,
>
>Mark
>
>
>On Monday 24 October 2011 07:37:47 Jim Adler wrote:
>> Yes, using 1.0.1 with LevelDB. I moved to it from Bitcask in the hopes
>>of better performance.
>> 
>> Good to hear about your 60M key use-case. Can you share any key access
>>performance numbers?
>> 
>> Jim
>> 
>> On Oct 24, 2011, at 7:23 AM, Mark Steele 
>>wrote:
>> 
>> > Just curious Kyle, you using the 1.0 series?
>> > 
>> > I've done some informal testing on a 3 node 1.0 cluster and key
>>listing was working just peachy on 60 million keys using bitcask as the
>>backend.
>> > 
>> > Cheers,
>> > 
>> > Mark
>> > 
>> > On Sunday 23 October 2011 12:26:35 Aphyr wrote:
>> >> On 10/23/2011 12:11 PM, Jim Adler wrote:
>> >>> I will be loosening the key filter criterion after I get the basics
>> >>> working, which I thought would be a simple equality check. 8M keys
>> >>> isn't really a large data set, is it? I thought that keys were
>>stored
>> >>> in memory and key filters just operated on those memory keys and not
>> >>> data.
>> >>> 
>> >>> Jim
>> >> 
>> >> That's about where we started seeing timeouts in list-keys. Around 25
>> >> million keys, list-keys started to take down the cluster. (6 nodes,
>>1024
>> >> partitions). You may not encounter these problems, but were I in your
>> >> position and planning to grow... I would prepare to stop using key
>> >> filters, bucket listing, and key listing early.
>> >> 
>> >> Our current strategy is to store the keys in Redis, and synchronize
>>them
>> >> with post-commit hooks and a process that reads over bitcask. With
>> >> ionice 3, it's fairly low-impact.
>>https://github.com/aphyr/bitcask-ruby
>> >> may be useful.
>> >> 
>> >> --Kyle
>> >> 
>> >>   # Simplified code, extracted from our bitcask scanner:
>> >>   def run
>> >> `renice 10 #{Process.pid}`
>> >> `ionice -c 3 -p #{Process.pid}`
>> >> 
>> >>   begin
>> >> bitcasks_dir = '/var/lib/riak/bitcask'
>> >> dirs = Dir.entries(bitcasks_dir).select do |dir|
>> >>   dir =~ /^\d+$/
>> >> end.map do |dir|
>> >>   File.join(bitcasks_dir, dir)
>> >> end
>> >> 
>> >> dirs.each do |dir|
>> >>   scan dir
>> >>   GC.start
>> >> end
>> >> log.info "Completed run"
>> >>   rescue => e
>> >> log.error "#{e}\n#{e.backtrace.join "\n"}"
>> >> sleep 10
>> >>   end
>> >> end
>> >>   end
>> >> 
>> >>   def scan(dir)
>> >> log.info "Loading #{dir}"
>> >> b = Bitcask.new dir
>> >> b.load
>> >> 
>> >> log.info "Updating #{dir}"
>> >> b.keydir.each do |key, e|
>> >>   bucket, key = BERT.decode(key).map { |x|
>> >> Rack::Utils.unescape x
>> >>   }
>> >>   # Handle determines what to do with this particular bucket/key
>> >>   # combo; e.g. insert into redis.
>> >>   handle bucket, key, e
>> >> end
>> >>   end
>> >> 
>> >> ___
>> >> 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

Newline in Key Legal

[Jim Adler]

I'm getting a crash when running a key filter query. It looks like the
problem is having a newline in a key name (see name-this\nBob in error
below).  Is there any restriction on key characters?

Jim

2011-10-24 05:08:14 =SUPERVISOR REPORT
 Supervisor: {local,riak_pipe_fitting_sup}
 Context:child_terminated
 Reason: 
{sink_died,{sink_died,{json_encode,{bad_term,{not_found,{<<"nodes">>,<<"name
-THIS
Bob">>},undefined}
 Offender:   
[{pid,<0.3428.0>},{name,undefined},{mfargs,{riak_pipe_fitting,start_link,und
efined}},{restart_type,temporary},{shutdown,2000},{child_type,worker}]



___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Newline in Key Legal

[Jim Adler]

Ok, this is a little simpler but I'm not sure how to proceed. When I pull
the keys via ?keys=stream API, I have a key "name-this\nBob". But
fetching it gets me a 404 not found error.  I've tried %0D%0A (and other
variants) in the API call but no luck.  Any way to delete this errant key?

Jim

From:  Jim Adler 
Date:  Mon, 24 Oct 2011 16:04:40 -0700
To:  "riak-users@lists.basho.com" 
Subject:  Newline in Key Legal

I'm getting a crash when running a key filter query. It looks like the
problem is having a newline in a key name (see name-this\nBob in error
below).  Is there any restriction on key characters?

Jim

2011-10-24 05:08:14 =SUPERVISOR REPORT
 Supervisor: {local,riak_pipe_fitting_sup}
 Context:child_terminated
 Reason: 
{sink_died,{sink_died,{json_encode,{bad_term,{not_found,{<<"nodes">>,<<"name
-THIS
Bob">>},undefined}
 Offender:   
[{pid,<0.3428.0>},{name,undefined},{mfargs,{riak_pipe_fitting,start_link,und
efined}},{restart_type,temporary},{shutdown,2000},{child_type,worker}]

___ 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

Re: Newline in Key Legal

[Jim Adler]

Hi Bryan - I'm now running 1.0.1 but the keys were inserted under 0.14.  I
tried your test and it worked fine.  So, maybe I'm caught between
inserting under an old version and now reading under another?

Thanks for your help.

Jim
 
On 10/25/11 7:02 AM, "Bryan Fink"  wrote:

>On Tue, Oct 25, 2011 at 12:54 AM, Jim Adler  wrote:
>> Ok, this is a little simpler but I'm not sure how to proceed. When I
>>pull
>> the keys via ?keys=stream API, I have a key "name-this\nBob".
>>But
>> fetching it gets me a 404 not found error.  I've tried %0D%0A (and other
>> variants) in the API call but no luck.  Any way to delete this errant
>>key?
>> Jim
>
>Hi, Jim.  Just %0A seems to work for me:
>
>$ curl -X PUT -H "content-type: text/plain"
>http://localhost:8098/riak/jim/one-two%0Athree --data "hello"
>
>$ curl http://localhost:8098/riak/jim?keys=true
>{Š"keys":["one-two\nthree"]}
>
>$ curl http://localhost:8098/riak/jim/one-two%0Athree
>hello
>
>$ curl -X DELETE http://localhost:8098/riak/jim/one-two%0Athree
>$ curl http://localhost:8098/riak/jim/one-two%0Athree
>not found
>
>That was on the tip of riak's master branch.  If you're still having
>trouble, could you please reply with the Riak version you're using (I
>know that 0.14 had an odd encoding behavior that was fixed in 1.0[1]),
>as well as your choice of client and a snippet or two of code?
>
>-Bryan
>
>[1] https://issues.basho.com/show_bug.cgi?id=617



___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Newline in Key Legal

[Jim Adler]

Hi Bryan - Thanks for the info but no dice. app.config http_url_encoding
is "on" but the key shows as not found.

Anything else I can try?

Jim

On 10/25/11 8:26 AM, "Bryan Fink"  wrote:

>On Tue, Oct 25, 2011 at 10:35 AM, Jim Adler  wrote:
>> Hi Bryan - I'm now running 1.0.1 but the keys were inserted under 0.14.
>> I
>> tried your test and it worked fine.  So, maybe I'm caught between
>> inserting under an old version and now reading under another?
>
>It's possible that your upgraded nodes are operating in compatibility
>mode wrt. key decoding, rather than using the 1.0 default behavior.
>Look in the riak_kv section of your app.config for the line:
>
> {http_url_encoding, on},
>
>If that's missing or set to 'compat' instead of 'on', then asking for
>"foo%0Abar" over HTTP will attempt to look up "foo%0Abar", not
>"foo\nbar".  There are two ways to access this key in 1.0, one
>request-level the other global.
>
>The request-level path is to use the X-Riak-URL-Encoding header:
>
>curl -H "X-Riak-URL-Encoding:on" http://.../foo%0Abar
>
>That will enable the 1.0 decoding behavior for just that request.
>
>The global path is to alter the aforementioned setting in your
>app.config and bounce the node.  Note that if you had any keys with
>percent signs or other invalid URL characters in them, though, you'll
>now have to encode those keys when requesting them (this is the reason
>for leaving upgraded nodes in 'compat' mode by default).
>
>-Bryan



___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Python Client Protocol Buffers Error

[Jim Adler]

I'm consistently seeing a key filter query fail with protocol buffers that
works fine with http.  I've seen similar problems reported
(http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-April/004
002.html, 
http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-October/00
6056.html, 
http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-January/00
3015.html). I am using the latest python client 1.3.0 which should have
fixed some of the earlier reported problems.

Any ideas?

Jim

Here's the stack trace:

2011-10-29 10:32:03 ERROR __main__,545 'Socket returned short packet
length \x00\x00\x00 - expected 4' Traceback (most recent call last):
  File 
"/Users/jadler/projects/dg/usr/jadler/projects/score/twitter/twitter_crawl.
py", line 270, in main for result in query.run(timeout=600):
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
ges/riak/mapreduce.py", line 211, in run result = t.mapred(self._inputs,
query, timeout)
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
ges/riak/transports/pbc.py", line 311, in mapred msg_code, resp =
self.recv_msg()
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
ges/riak/transports/pbc.py", line 365, in recv_msg self.recv_pkt()
  File 
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
ges/riak/transports/pbc.py", line 410, in recv_pkt format(nmsglen))
RiakError: 'Socket returned short packet length \x00\x00\x00 - expected 4'



___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Python Client Protocol Buffers Error

[Jim Adler]

Ried, 

Riak 1.0.1 from package, Ubuntu 11.04

Jim

From:  Reid Draper 
Date:  Sat, 29 Oct 2011 13:47:02 -0400
To:  Jim Adler 
Cc:  "riak-users@lists.basho.com" 
Subject:  Re: Python Client Protocol Buffers Error

Jim,

What version of Riak are you using? Are you using a package or did you build
from source? If you built from source, what version of Erlang are you using?

Reid

On Sat, Oct 29, 2011 at 1:38 PM, Jim Adler  wrote:
> I'm consistently seeing a key filter query fail with protocol buffers that
> works fine with http.  I've seen similar problems reported
> (http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-April/004
> 002.html 
> <http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-April/004002
> .html> ,
> http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-October/00
> 6056.html 
> <http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-October/0060
> 56.html> ,
> http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-January/00
> 3015.html 
> <http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-January/0030
> 15.html> ). I am using the latest python client 1.3.0 which should have
> fixed some of the earlier reported problems.
> 
> Any ideas?
> 
> Jim
> 
> Here's the stack trace:
> 
> 2011-10-29 10:32:03 ERROR __main__,545 'Socket returned short packet
> length \x00\x00\x00 - expected 4' Traceback (most recent call last):
>   File
> "/Users/jadler/projects/dg/usr/jadler/projects/score/twitter/twitter_crawl.
> py", line 270, in main for result in query.run(timeout=600):
>   File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
> ges/riak/mapreduce.py", line 211, in run result = t.mapred(self._inputs,
> query, timeout)
>   File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
> ges/riak/transports/pbc.py", line 311, in mapred msg_code, resp =
> self.recv_msg()
>   File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
> ges/riak/transports/pbc.py", line 365, in recv_msg self.recv_pkt()
>   File
> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
> ges/riak/transports/pbc.py", line 410, in recv_pkt format(nmsglen))
> RiakError: 'Socket returned short packet length \x00\x00\x00 - expected 4'
> 
> 
> 
> ___
> 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

Re: Python Client Protocol Buffers Error

[Jim Adler]

Attached is the app.config and here's the code snippet:

import riak

client = riak.RiakClient(host='xxx.xxx.xxx.xxx', port=8087,
transport_class=riak.RiakPbcTransport)

query = riak.RiakMapReduce(client).add('nodes')

query.add_key_filters(riak.key_filter.tokenize('-', 2) +
riak.key_filter.starts_with('jim'))

query.map('''

function(v) {

return [[v.key]];

}''')

for result in query.run(timeout=600):

print '%s' % (result)


Thanks!

Jim

From:  Reid Draper 
Date:  Sat, 29 Oct 2011 16:13:03 -0400
To:  Jim Adler 
Cc:  "riak-users@lists.basho.com" 
Subject:  Re: Python Client Protocol Buffers Error

Do you have some code that you can send to reproduce the issue? Would you
mind sending your app.config as well?

On Sat, Oct 29, 2011 at 3:58 PM, Jim Adler  wrote:
> Ried, 
> 
> Riak 1.0.1 from package, Ubuntu 11.04
> 
> Jim
> 
> From:  Reid Draper 
> Date:  Sat, 29 Oct 2011 13:47:02 -0400
> To:  Jim Adler 
> Cc:  "riak-users@lists.basho.com" 
> Subject:  Re: Python Client Protocol Buffers Error
> 
> Jim,
> 
> What version of Riak are you using? Are you using a package or did you build
> from source? If you built from source, what version of Erlang are you using?
> 
> Reid
> 
> On Sat, Oct 29, 2011 at 1:38 PM, Jim Adler  wrote:
>> I'm consistently seeing a key filter query fail with protocol buffers that
>> works fine with http.  I've seen similar problems reported
>> (http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-April/004
>> 002.html 
>> <http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-April/00400
>> 2.html> ,
>> http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-October/00
>> 6056.html 
>> <http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-October/006
>> 056.html> ,
>> http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-January/00
>> 3015.html 
>> <http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-January/003
>> 015.html> ). I am using the latest python client 1.3.0 which should have
>> fixed some of the earlier reported problems.
>> 
>> Any ideas?
>> 
>> Jim
>> 
>> Here's the stack trace:
>> 
>> 2011-10-29 10:32:03 ERROR __main__,545 'Socket returned short packet
>> length \x00\x00\x00 - expected 4' Traceback (most recent call last):
>>   File
>> "/Users/jadler/projects/dg/usr/jadler/projects/score/twitter/twitter_crawl.
>> py", line 270, in main for result in query.run(timeout=600):
>>   File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
>> ges/riak/mapreduce.py", line 211, in run result = t.mapred(self._inputs,
>> query, timeout)
>>   File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
>> ges/riak/transports/pbc.py", line 311, in mapred msg_code, resp =
>> self.recv_msg()
>>   File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
>> ges/riak/transports/pbc.py", line 365, in recv_msg self.recv_pkt()
>>   File
>> "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packa
>> ges/riak/transports/pbc.py", line 410, in recv_pkt format(nmsglen))
>> RiakError: 'Socket returned short packet length \x00\x00\x00 - expected 4'
>> 
>> 
>> 
>> ___
>> riak-users mailing list
>> riak-users@lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> 





app.config
Description: Binary data
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Riak 1.0.2 RC1

[Jim Adler]

RE: large ring size warning in the release notes, is the performance 
degradation linear below 256? That is, until the major release that fixes this, 
is it best to keep ring sizes at 64 for best performance?

Jim

Sent from my phone. Please forgive the typos. 

On Nov 4, 2011, at 7:20 PM, Jared Morrow  wrote:

> As we've mentioned earlier, the 1.0.2 release of Riak is coming soon.   Like 
> we did with Riak 1.0.0, we are provided a release candidate for test before 
> we release 1.0.2 final.
> 
> You can find the packages here:
> http://downloads.basho.com/riak/riak-1.0.2rc1/
> 
> The release notes have been updated and can be found here:  
> https://github.com/basho/riak/blob/1.0/RELEASE-NOTES.org
> 
> Thank you, as always, for continuing to provide bug reports and feedback.
> 
> -Jared
> ___
> 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

Re: Riak 1.0.2 RC1

[Jim Adler]

Thanks for the detailed response Joe.  We're at 256 partition ring size
which seems, a little high, but within your guidance.

Jim

On 11/6/11 8:10 PM, "Joseph Blomstedt"  wrote:

>> RE: large ring size warning in the release notes, is the performance
>> degradation linear below 256? That is, until the major release that
>>fixes
>> this, is it best to keep ring sizes at 64 for best performance?
>
>The large ring size warning in the release notes is predominately
>related to an issue with Riak's ring gossip functionality.
>Adding/removing nodes, changing bucket properties, and setting cluster
>metadata all result in a brief period (usually a few seconds) where
>gossip traffic increases significantly. The size of the ring
>determines both the number of gossip messages that occur during this
>window, as well as the size of each message. With large rings, it is
>possible that messages are generated faster than they can be handled,
>resulting in large message queues that impact cluster performance and
>tie up system memory until the message queues are fully drained. In
>general, there is no problem as long as your hardware is fast enough
>to process the brief spike in gossip traffic in close to real time.
>Concerning this specific issue, choosing a ring size smaller than the
>maximum you can handle does not provide any additional performance
>gains.
>
>However, unrelated to this issue, there are general performance
>considerations related to ring size versus the number of nodes in your
>cluster. Given a fixed number of nodes, a larger ring results in more
>vnodes per node. This allows more process concurrency which may
>improvement performance. However, each vnode runs it's own backend
>instance that has it's own set of on-disk files, and competing
>reads/writes to different files may result in additional I/O
>contention than having fewer vnodes per node. The overall performance
>is going to depend largely on your OS, your file system, and your
>traffic pattern. So, it's hard to give specific hard and fast rules.
>The other issue is 2I performance. Secondary indexes send request to a
>covering set of vnodes, which works out to ring_size / N requests;
>therefore increasing the ring_size without increasing N leads to more
>2I requests. Again, the right answer depends largely on your use case.
>
>Overall, I believe we normally recommend between 10 and 50 vnodes per
>node, with the ring size rounded up to the next power of two.
>Personally, I think 16 vnodes per node is a good number, which matches
>the common 64 partition, 4 node Riak cluster. Thus, choosing a ring
>size based on that ratio and your expected number of future nodes is a
>reasonable choice. Just be sure to stay under 1024 until the issue
>with gossip overloading the cluster is resolved.
>
>-Joe
>
>On Sat, Nov 5, 2011 at 9:49 AM, Jim Adler  wrote:
>> RE: large ring size warning in the release notes, is the performance
>> degradation linear below 256? That is, until the major release that
>>fixes
>> this, is it best to keep ring sizes at 64 for best performance?
>> Jim
>>
>> Sent from my phone. Please forgive the typos.
>> On Nov 4, 2011, at 7:20 PM, Jared Morrow  wrote:
>>
>> As we've mentioned earlier, the 1.0.2 release of Riak is coming soon.
>>Like
>> we did with Riak 1.0.0, we are provided a release candidate for test
>>before
>> we release 1.0.2 final.
>> You can find the packages here:
>> http://downloads.basho.com/riak/riak-1.0.2rc1/
>> The release notes have been updated and can be found here:
>>  https://github.com/basho/riak/blob/1.0/RELEASE-NOTES.org
>> Thank you, as always, for continuing to provide bug reports and
>>feedback.
>> -Jared
>>
>> ___
>> 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
>>
>>
>
>
>
>-- 
>Joseph Blomstedt 
>Software Engineer
>Basho Technologies, Inc.
>http://www.basho.com/



___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

2i Performance on EC2

[Jim Adler]

I'm running 6 nodes on EC2 with load balancing and instance storage.  I'm
seeing an average of 115 ms per index.run() using a single _bin index,
protocol buffers, and python client.  A regular get() is about 40 ms which
is acceptable for my application.

Has anyone done any tuning to get the 2i run() closer to the 40 ms of a key
get()?

Thanks!

Jim


___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Secondary Indexes - Feedback?

[Jim Adler]

Speed.  I'm running 6 nodes on EC2 with load balancing and instance storage.
I'm seeing an average of 115 ms per index.run() using a single _bin index,
protocol buffers, and python client.  A regular get() is about 40 ms.  How
can I get faster access with 2i?

Jim

From:  Rusty Klophaus 
Date:  Wed, 16 Nov 2011 12:57:48 -0500
To:  "riak-users@lists.basho.com" 
Subject:  Secondary Indexes - Feedback?

Hello Riak Users,

The Basho team recently released Riak 1.0 which introduced a new
feature called Secondary Indexes. This feature allows you to tag Riak
objects with additional metadata, and then later query the indexed
metadata to retrieve the objects.

(See http://wiki.basho.com/Secondary-Indexes.html)

Now that you've had a few weeks to investigate and experiment with
Secondary Indexes, I'm hoping to hear about your experiences to help
us focus future development efforts most effectively:
* Have you tried Secondary Indexes?
* Does the feature help solve your problems? If not, why not? Any concerns?
* What is your wish list for the future of Secondary Indexes?
Please feel free to respond either publicly or privately to this
email, and thanks for your help!

Best,
Rusty

-- 
Rusty Klophaus (@rustyio)
Basho Technologies, Inc.
www.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

Python Client Thread Safe?

[Jim Adler]

I'm getting the following error while using protocol buffers
(RiakPbcTransport) with more than one thread (stack trace below):

Socket returned short packet length 0 - expected 4'

I'm using the 1.3.0 Python client on Mac and Ubuntu 11.04 and have seen
the same error on both OS's. A single-thread works fine as does the
RiakHttpTransport.

Anyone have this problem?

Thanks,
Jim

File 
"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/li
b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/bucket.py", line 260,
in get
return obj.reload(r)
  File 
"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/li
b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/riak_object.py", line
373, in reload
Result = t.get(self, r, vtag)
  File 
"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/li
b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
line 195, in get
msg_code, resp = self.send_msg(MSG_CODE_GET_REQ, req, None)
  File 
"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/li
b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
line 387, in send_msg
return self.recv_msg(conn, expect)
  File 
"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/li
b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
line 413, in recv_msg
self.recv_pkt(conn)
  File 
"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/li
b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
line 460, in recv_pkt
len(nmsglen))
RiakError: 'Socket returned short packet length 0 - expected 4'


___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: Python Client Thread Safe?

[Jim Adler]

Hmm, I do have multiple clients -- one per thread.

Jim

On 2/27/12 10:47 AM, "Armon Dadgar"  wrote:

>Hey Jim,
>
>The PBC client does not share any state between clients,
>but it is not safe to use a single client with multiple threads,
>since the underlying socket will be shared.
>
>If you have multiple threads, just make sure to use multiple
>clients.
>
>Best Regards,
>
>Armon Dadgar
>
>> 
>> Message: 1
>> Date: Sun, 26 Feb 2012 19:39:38 +
>> From: Jim Adler 
>> To: "riak-users@lists.basho.com" 
>> Subject: Python Client Thread Safe?
>> Message-ID: 
>> Content-Type: text/plain; charset="us-ascii"
>> 
>> I'm getting the following error while using protocol buffers
>> (RiakPbcTransport) with more than one thread (stack trace below):
>> 
>>  Socket returned short packet length 0 - expected 4'
>> 
>> I'm using the 1.3.0 Python client on Mac and Ubuntu 11.04 and have seen
>> the same error on both OS's. A single-thread works fine as does the
>> RiakHttpTransport.
>> 
>> Anyone have this problem?
>> 
>> Thanks,
>> Jim
>> 
>> File 
>> 
>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/
>>li
>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/bucket.py", line
>>260,
>> in get
>>return obj.reload(r)
>>  File 
>> 
>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/
>>li
>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/riak_object.py",
>>line
>> 373, in reload
>>Result = t.get(self, r, vtag)
>>  File 
>> 
>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/
>>li
>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
>> line 195, in get
>>msg_code, resp = self.send_msg(MSG_CODE_GET_REQ, req, None)
>>  File 
>> 
>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/
>>li
>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
>> line 387, in send_msg
>>return self.recv_msg(conn, expect)
>>  File 
>> 
>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/
>>li
>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
>> line 413, in recv_msg
>>self.recv_pkt(conn)
>>  File 
>> 
>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7/
>>li
>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
>> line 460, in recv_pkt
>>len(nmsglen))
>> RiakError: 'Socket returned short packet length 0 - expected 4'
>> 
>
>___
>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

Re: Python Client Thread Safe?

[Jim Adler]

Greg,

Thanks for the comments.  I'll do some tests along the lines of what you
suggest.

FWIW, I'm using Riak 1.0.3.

Jim

On 2/27/12 7:46 PM, "Greg Stein"  wrote:

>]
>X-pstn-settings: 3 (1.:0.1000) s cv GT3 gt2 gt1 r p m c
>X-pstn-addresses: from  [db-null]
>
>To clarify my thread-sharing comments: those are with respect to the
>unreleased client. And I've checked: the Bucket objects are sharable,
>too. Obviously, not if multiple threads are calling competing .set_r()
>or somesuch on the client or bucket. The short answer is share Client
>and Bucket objects to get access to Objects, and keep those
>per-thread.
>
>The underlying transport will manage multiple connections,
>persistently, in a thread-safe manner.
>
>(and I'm unclear on threading issues for the 1.3.0 python client)
>
>Cheers,
>-g
>
>On Mon, Feb 27, 2012 at 22:37, Greg Stein  wrote:
>> IIRC, that error was seen when connecting to Riak 0.14.0. What version
>>of
>> Riak are you connecting to?
>>
>> I might also suggest using the current, unreleased Python client from
>>the
>> master branch on GitHub. It has much better support for threads and
>> persistent connections. Just don't use variant client_id values and PB
>> connections (switch to Riak 1.1 and ignore client_id).
>>
>> One Client can be shared across threads, but not Objects. I don't recall
>> whether Buckets can be shared.
>>
>> Cheers,
>> -g
>>
>> On Feb 26, 2012 2:39 PM, "Jim Adler"  wrote:
>>>
>>> I'm getting the following error while using protocol buffers
>>> (RiakPbcTransport) with more than one thread (stack trace below):
>>>
>>>Socket returned short packet length 0 - expected 4'
>>>
>>> I'm using the 1.3.0 Python client on Mac and Ubuntu 11.04 and have seen
>>> the same error on both OS's. A single-thread works fine as does the
>>> RiakHttpTransport.
>>>
>>> Anyone have this problem?
>>>
>>> Thanks,
>>> Jim
>>>
>>> File
>>>
>>> 
>>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7
>>>/li
>>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/bucket.py", line
>>>260,
>>> in get
>>>return obj.reload(r)
>>>  File
>>>
>>> 
>>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7
>>>/li
>>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/riak_object.py",
>>>line
>>> 373, in reload
>>>Result = t.get(self, r, vtag)
>>>  File
>>>
>>> 
>>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7
>>>/li
>>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
>>> line 195, in get
>>>msg_code, resp = self.send_msg(MSG_CODE_GET_REQ, req, None)
>>>  File
>>>
>>> 
>>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7
>>>/li
>>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
>>> line 387, in send_msg
>>>return self.recv_msg(conn, expect)
>>>  File
>>>
>>> 
>>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7
>>>/li
>>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
>>> line 413, in recv_msg
>>>self.recv_pkt(conn)
>>>  File
>>>
>>> 
>>>"/usr/local/Cellar/python/2.7.2/Frameworks/Python.framework/Versions/2.7
>>>/li
>>> b/python2.7/site-packages/riak-1.3.0-py2.7.egg/riak/transports/pbc.py",
>>> line 460, in recv_pkt
>>>len(nmsglen))
>>> RiakError: 'Socket returned short packet length 0 - expected 4'
>>>
>>>
>>> ___
>>> 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

Re: riak-python-client2, a rewrite of the official client

[Jim Adler]

This is great Shuhao! 

I've had problems using the python client using multiple threads with protocol 
buffers. The exact same multithreaded code works fine with http protocol. So, 
any attention you can give to the pbc transport would be hugely appreciated.

Good luck! Can't wait to give your new client a test drive.

Jim

Sent from my phone. Please forgive the typos. 

On Mar 11, 2012, at 12:31 PM, Shuhao Wu  wrote:

> Hey guys,
> 
> I've been working with riak and python for the past couple of months, and I'm 
> at the point where I'm ready to completely reimplement riak-python-client. 
> So.. I did/started. The project is hosted on github and under the same apache 
> 2 license as the original client.
> 
> https://github.com/ultimatebuster/riak-python-client2
> 
> Couple of key highlights right now:
> 
>  1. 2 layers of API, a very basic layer (Transports), which handles 
> communicating with the server, and a high level API, which consists of 
> Bucket, Object, and so on.
>  2. Eliminated things like `set_` and `get_`. Made them just variables where 
> possible
> 
> I'm still taking suggestions for how to reimplement RiakObject (now called 
> RObject). Any feedback will be appreciated.
> 
> Cheers,
> 
> Shuhao
> ___
> 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