Hi,
The client you are trying to use is the internal Riak client. This will work if
you attach [1] to the Riak console and want to query Riak. If you are writing
an application to be run from outside Riak, you should instead use the Riak PB
Erlang Client [2].
Best regards,
Christian
[1]
htt
You can, I've done this, you have to modify the /etc/riak/vm.args to
include and start your application (assuming your application has a start/0)
function.
So if you have a foo app, you can add something like
-pa /usr/lib/erlang/lib/foo-0.0.0/ebin
-s foo_app
Then if foo_app.erl has something lik
On Fri, Jan 21, 2011 at 4:40 AM, Ryan Zezeski wrote:
> I was hesitant to mention it at first, but since you broke the ice...I also
> wrote my own pool. However, I took a different approach. My pool only
> cares about doling out connections and making sure they are alive. One or
> more processes
Just thought I'm chime is as I also just recently wrote a client pool, which
works in a very different way from these two.
The problem that I see with both solutions presented, is that in order
to get a client you have to route through a gen_server call, so you are
bottlenecking yourself if you ev
I was hesitant to mention it at first, but since you broke the ice...I also
wrote my own pool. However, I took a different approach. My pool only
cares about doling out connections and making sure they are alive. One or
more processes could use the same conn at a given time (side question: is
th
I am not sure if this is any help but I have uploaded a protocol buffer pool
client for riak which requires you to pass a client_id for each operation.
https://github.com/DangerDawson/riakc_pb_pool
It is very very basic, but does most of the useful things:
- put / get / delete
-
Another issue we've run into is that the Erlang native client allows
you to store non-binary values, which can not be accessed from the
PBC so if you're not careful or don't know better, you'll be in
for some migration if you're trying to use other clients.
The only real problem is that the PB
Agreed. So it therefore makes sense to start using the PBC from the outset,
allowing for future moving of the client app off any cluster node(s) it might
be residing on, as well as not being affecting by any subtle changes to the
internals of the riak_kv code base (specifically the non-PB module
To me the major concern is that if you use the native (non-PB)
interface, your application cluster and the Riak cluster become merged
into one big Erlang cluster. The number of TCP connections can start
getting out of hand, and the work put on the cluster manager starts to
become significant.
_
Additionally, the native Erlang client is more sensitive to internal
changes in Riak than any well defined protocol would be.
On Thu, Jan 20, 2011 at 9:35 PM, Ryan Maclear wrote:
> Thanks, that makes sense. I guess most of the sample code is based on the
> dev setup outlined in the Fast Track on
Thanks, that makes sense. I guess most of the sample code is based on the dev
setup outlined in the Fast Track on the wiki, which only sets up four local
nodes.
Cheers,
Ryan
On 20 Jan 2011, at 2:46 PM, Ryan Zezeski wrote:
> I think one thing to note is that by using riak_client all your data
I think one thing to note is that by using riak_client all your data will go
over the distributed socket, which I suppose could interfere with other
messages and act as a bottleneck. With PBC you can open multiple sockets as
needed and your node won't be connected to the riak cluster, which probab
12 matches
Mail list logo
