update document

Bryan Fink bryan at basho.com
Thu Nov 5 15:46:09 EST 2009


On Thu, Nov 5, 2009 at 2:18 PM, francisco treacy
<francisco.treacy at gmail.com> wrote:
> I have released the Scala library for Riak, and I've actually got a
> couple of questions/ issues:
>
> 1. find_all => what would be the natural approach to implement this function?
>
> Looks like right now I have to GET /bucket/ , grab the keys array, and
> do a single GET per key. Or am I missing something?

The way we've been approaching this is to use link-walking for
bulk-GET.  Basically, make sure an object exists that has links to all
of the objects you want in your bulk-get, and issue the link walking
query.

So, if you want to get /x/a, /x/b, and /x/c all at once, create object
/q/r with links to all three, and GET /q/r/_,_,_

> 2. vclocks => sometimes extremely long (vastly outweighing the object
> itself), or those were edge cases in my test scenarios?

Part of this is an artifact of the path we took in creating the HTTP
interfaces, but as of just a few hours ago, you have a way to fight
back: the X-Riak-ClientId header.

The basic problem is that the vclock of an object grows linearly
relative to the number of actors modifying it.  Until today, each
request through the HTTP interface looked like a different actor, so
the vclock grew linearly relative to the number of HTTP requests
modifying the object (oops).

The tool you can use now is the X-Riak-ClientId header.  Just make
each of your actors use a unique value for this header, and you'll see
vclocks stay much smaller.

(Btw, if you were using the Javascript or Ruby client libraries, just
pulling down the tip of the bitbucket repo alone will help you, if you
do things like only create one JiakClient per session.  The JiakClient
will create a random ClientId for you, and use it for every request,
giving you a actor-per-session model without changing any of your
current code.  This behavior will be coming soon to the Python, Java,
and PHP libraries too (and I assume your Scala one as well ;).)

> 3. I usually lose connection to Riak overnight - but today it happened
> once, while I was working. (I use config/riak-demo.erlenv and version
> from a couple of days ago with attachment support via HTTP).
>  It won't connect, but if I try to ./start-fresh without killing
> related processes first, it will start throwing strange 500-something
> server errors, no matter what request.

Which connection are you referring to here?  If you're talking about
the shell connection to the erlang node, it probably has to do with
that shell not behaving well if it doesn't have a terminal attached.
You might need to run that terminal in a "screen" session or use the
-detached command line flag for erl.

> 4. A pain in the butt to kill (I use config/riak-demo.erlenv)
> I know about "killall heart", but sometimes I need to issue that
> command twice and still then ps for erlang processes, having to kill
> epmd as well. Failing to do so upon ./start-fresh will bring the
> aforementioned 500 server errors.

We agree!  We core devs have internalized the machinations needed to
shut Riak down, but it's annoying even to us sometimes.  A much better
start/stop script is planned for the next release of Riak.

In the meantime, I'd recommend using init:stop/0 (through an
rpc:call/4 on the riak node, if necessary).  It's supposed to have
better behavior when heart is involved.

-Bryan




More information about the riak-users mailing list