Thank you for your quick responses.
Here are the output of "ifconfig -a" from these three VMs:
--No.1
eth0 Link encap:Ethernet HWaddr 08:00:27:8F:13:9F
inet addr:192.168.56.101 Bcast:192.168.56.255 Mask:255.255.255.
Does anyone have any experience or know of any reasons to avoid running a Riak
cluster with different filesystems backing different nodes?
With all other cluster components (hardware, OS, Riak version, Riak backend
[leveldb], etc.) being equal, I'm really interested in doing a comparison of a
Awesome - thanks for the info. I'm planning on launching in step with 2.0,
so very cool stuff.
Dave
On Fri, Oct 18, 2013 at 2:37 PM, Matthew Von-Maszewski
wrote:
> Darren
>
> File cache is favored over block cache. The cost of a miss to the file
> cache is much larger than a miss to the block
Pretty much right after getting the basics of a TCP client put together for
Reactor [1] I started working on Riak integration. Mostly as a way to
test/validate the classes in Reactor by stretching them with a real use-case.
The result is a project I'm working on called Riaktor [2].
I think the
It does in fact appear that the out of synch system clocks across the nodes was
causing the issue with vclock auto conflict resolution. The nodes don’t have
internet access so I set up an internal ntp server to keep them in synch from
now on. Thanks again for all the help!
Dave
On Oct 23, 2013
Hello Houm,
Could you provide the output of "ifconfig -a" from these three VMs? Are you
using NAT or host-only networking?
--
Luke Bakken
CSE
lbak...@basho.com
On Wed, Oct 23, 2013 at 6:24 PM, wrote:
> Hello All,
>
> I have setup three VMs using VirtualBox running centos and installed
> riak-
Hi Mark,
Thank you very much, you are right. It was wrong hosts/ip in /etc/hosts. As
result - connection timeout to these hosts.
Best regards,
Sergey
2013/10/23 Mark Phillips
> Hi Sergey,
>
> This looks like the initial tcp connection is timing out when riak@de5
> and riak@de6 are first tryin
