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 PBC needs some additional software around it to pool connections, where the Erlang native client got that for free because it was leveraging Erlang distribution. On Fri, Jan 21, 2011 at 3:57 AM, Ryan Maclear <r...@lambdasphere.com> wrote: > 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 modules). > > On 20 Jan 2011, at 9:37 PM, Mojito Sorbet wrote: > >> 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. >> >> >> _______________________________________________ >> 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
