It's happened again. The crash and error logs look pretty much the same.
On Sat, Aug 10, 2013 at 8:17 AM, Lucas Cooper wrote:
> I had a crash of an entire cluster early this morning, I'm not entirely
> sure why, seems to be something with the indexer or Protocol Buffers (or my
> use of them). He
And another one... I thought the point of Erlang was that this kind of
thing wasn't meant to happen ._.
On Sat, Aug 10, 2013 at 6:12 PM, Lucas Cooper wrote:
> It's happened again. The crash and error logs look pretty much the same.
>
>
> On Sat, Aug 10, 2013 at 8:17 AM, Lucas Cooper wrote:
>
>>
I won't have time to look at these logs in more detail until later,
but are you sure you're not getting OOM killed? Usually there is some
sign of what happened when a node went down in console.log as well,
but it just sort of ends. Check the syslog for OS messages, you
might find something there
Yes, Search indexing is enabled.
On 10/08/2013 11:27 PM, "Russell Brown" wrote:
> Are you using riak search?
>
> On 9 Aug 2013, at 18:17, Lucas Cooper wrote:
>
> > I had a crash of an entire cluster early this morning, I'm not entirely
> sure why, seems to be something with the indexer or Protoc
Are you using riak search?
On 9 Aug 2013, at 18:17, Lucas Cooper wrote:
> I had a crash of an entire cluster early this morning, I'm not entirely sure
> why, seems to be something with the indexer or Protocol Buffers (or my use of
> them). Here are the various logs: http://egf.me/logs.tar.xz
>
Hey Lucas,
Like Evan, I haven't had time to dig into the logs. Just so we know what
the baseline is here:
* How many nodes of Riak?
* What version of Riak?
* What type of hardware?
* What's your open files limit [1] ?
Mark
[1] http://docs.basho.com/riak/latest/ops/tuning/open-files-limit/
Just a quick follow up, I did this exact approach and things went
smoothly as expected. I had forgotten that stopping a node does not
mark the node as "down" indicating that vnodes should be handed off.
One last step I would add is that the log directory also needs to be
changed in the vm.args fil
Hi,
I've just rolled up my sleeves and have started to make my application more
robust with conflict resolution.
I am currently using a @RiakVClock in my POJO (I need to think more about
whether the read/modify/write approach is preferable or whether I'd have to
rearchitect things).
I read in th
I'm sure Roach will correct me if I'm off-base, but I believe the store
operation does a fetch and resolve before writing. I think the ideal way to
do that is to create a Mutation (T being your POJO) as well, in which
case it's less of a "store" and more of a "fetch-modify-write". The way to
skip t
Thanks Sean. I understand that the fetch-modify-write is the approach that
I'm *not* taking in this case, as I am using withoutFetch() and setting a
@RiakVClock in my POJO.
I just need to weigh up whether the ideal way is sufficiently better to
rejig bits of my code - but I think that's a differen
10 matches
Mail list logo