Hi Ryan,
Thanks for the help.
Now I’m working with riak 2.0 pre17, have tried both set bucket property
search_index to other index or _dont_index_, but still cannot delete the index.
Failure: riakasaurus.exceptions.RiakPBCException: Can't delete index with
associate buckets [<<"riakasaurus.tes
Hi Yaochitc,
Answers below:
On Mar 11, 2014, at 2:47 AM, yaochitc wrote:
> Hello, I'm trying to do some test with a riak consist of 8 nodes. I tried to
> leave a node from the cluster, and I can see the ownership handoff through
> ring-status.But when I tried to remove a node, such process did
A few things:
1. can you provide the output from `riak-admin member-status`?
2. using five VMs per physical node likely means that you're bottleneck is
that host running the VMs not Riak
3. uses a shared disk via iSCSI for storage is most certainly also a
bottleneck
A benchmark that scales linear
Kria (a right rotation of "Riak") is an open source asynchronous Clojure
driver for Riak 2.0 built on top of Java 7's NIO.2. It uses Riak's protocol
buffer interface.
https://github.com/bluemont/kria
https://clojars.org/kria
In my work projects, we have found that Clojure's core.async works great
On Tue, Mar 11, 2014 at 4:17 AM, EmiNarcissus wrote:
>
> Now I'm working with riak 2.0 pre17, have tried both set bucket property
> search_index to other index or _dont_index_, but still cannot delete the
> index.
>
>
> Failure: riakasaurus.exceptions.RiakPBCException: Can't delete index with
> as
Hi everyone, we are running Riak 1.4.1 on RHEL 6.2 using bitcask. We are
using protobufs with the Java client, and our binary objects are typically
a few hundred KB in size. I have noticed a persistent anomaly with riak
reads and writes. It seems like often, maybe 0.5% of the time, writing to
Riak
Hi Matthew,
I believe 60 seconds is the default timeout in the client, so it is
possible the `busy_dist_port` issues have caused a timeout and that the
automatic retry then has succeeded.
A small +zdbbl value will cause the internal buffers to fill up and result
in `busy_dist_port` messages, whic
