Re: Java Riak client can't handle a Riak node failure?

Thanks very much for the advice. I'll give it a good test and then write something. Somewhere. Cheers. On Mon, Feb 22, 2016 at 3:42 PM, Alex Moore wrote: > If the contract is "Return true iff the object existed", then the second > fetch is superfluous + so is the async example

Re: Java Riak client can't handle a Riak node failure?

If the contract is "Return true iff the object existed", then the second fetch is superfluous + so is the async example I posted. You can use the code you had as-is. Thanks, Alex On Mon, Feb 22, 2016 at 1:23 PM, Vanessa Williams < vanessa.willi...@thoughtwire.ca> wrote: > Hi Alex, would a

Re: Java Riak client can't handle a Riak node failure?

Hi Alex, would a second fetch just indicate that the object is *still* deleted? Or that this delete operation succeeded? In other words, perhaps what my contract really is is: return true if there was already a value there. In which case would the second fetch be superfluous? Thanks for your

Re: Java Riak client can't handle a Riak node failure?

> > That's the correct behaviour: it should return true iff a value was > actually deleted. Ok, if that's the case you should do another FetchValue after the deletion (to update the response.hasValues()) field, or use the async version of the delete function. I also noticed that we weren't

Re: Java Riak client can't handle a Riak node failure?

See inline: On Mon, Feb 22, 2016 at 10:31 AM, Alex Moore wrote: > Hi Vanessa, > > You might have a problem with your delete function (depending on it's > return value). > What does the return value of the delete() function indicate? Right now > if an object existed, and was

Re: Java Riak client can't handle a Riak node failure?

Hi Vanessa, You might have a problem with your delete function (depending on it's return value). What does the return value of the delete() function indicate? Right now if an object existed, and was deleted, the function will return true, and will only return false if the object didn't exist or

Re: Java Riak client can't handle a Riak node failure?

Hi Dmitri, this thread is old, but I read this part of your answer carefully: You can use the following strategies to prevent stale values, in increasing > order of security/preference: > 1) Use timestamps (and not pass in vector clocks/causal context). This is > ok if you're not editing objects,

Re: Java Riak client can't handle a Riak node failure?

Alexander, thanks for that reminder. Yes, n_val = 2 would suit us better. I'll look into getting that tested. Regards, Vanessa On Thu, Oct 8, 2015 at 1:04 PM, Alexander Sicular wrote: > Greetings and salutations, Vanessa. > > I am obliged to point out that running n_val of

Re: Java Riak client can't handle a Riak node failure?

Hi Dmitri, your point about r=2 is noted. I'll probably go with that. The thing I have to decide is how to reconcile duplicates. For the time being I can tolerate some stale data/inconsistency (caused by r=1). But for the future I would prefer not to risk that. Thanks to everyone for their help

Re: Java Riak client can't handle a Riak node failure?

Hi Vanessa, The thing to keep in mind about read repair is -- it happens asynchronously on every GET, but /after/ the results are returned to the client. So, when you issue a GET with r=1, the coordinating node only waits for 1 of the replicas before responding to the client with a success, and

Re: Java Riak client can't handle a Riak node failure?

Greetings and salutations, Vanessa. I am obliged to point out that running n_val of 3 (or more) is highly detrimental in a cluster size smaller than 5 nodes. Needless to say, it is not recommended. Let's talk about why that is the case for a moment. The default level of abstraction in Riak is

Re: Java Riak client can't handle a Riak node failure?

Glad you sorted it out! (I do want to encourage you to bump your R setting to at least 2, though. Run some tests -- I think you'll find that the difference in speed will not be noticeable, but you do get a lot more data resilience with 2.) On Wed, Oct 7, 2015 at 6:24 PM, Vanessa Williams <

Re: Java Riak client can't handle a Riak node failure?

Hi Dmitri, what would be the benefit of r=2, exactly? It isn't necessary to trigger read-repair, is it? If it's important I'd rather try it sooner than later... Regards, Vanessa On Wed, Oct 7, 2015 at 4:02 PM, Dmitri Zagidulin wrote: > Glad you sorted it out! > > (I do

Java Riak client can't handle a Riak node failure?

Hi all, we are still (for a while longer) using Riak 1.4 and the matching Java client. The client(s) connect to one node in the cluster (since that's all it can do in this client version). The cluster itself has 4 nodes (sorry, we can't use 5 in this scenario). There are 2 separate clients. We've

Re: Java Riak client can't handle a Riak node failure?

Hi Dmitri, thanks for the quick reply. It was actually our sysadmin who tried the load balancer approach and had no success, late last evening. However I haven't discussed the gory details with him yet. The failure he saw was at the application level (i.e. failure to read a key), but I don't know

Re: Java Riak client can't handle a Riak node failure?

Hi Vanessa, Riak is definitely meant to run behind a load balancer. (Or, at the worst case, to be load-balanced on the client side. That is, all clients connect to all 4 nodes). When you say "we did try putting all 4 Riak nodes behind a load-balancer and pointing the clients at it, but it didn't

Re: Java Riak client can't handle a Riak node failure?

Yeah, definitely find out what the sysadmin's experience was, with the load balancer. It could have just been a wrong configuration or something. And yes, that's the documentation page I recommend - http://docs.basho.com/riak/latest/ops/advanced/configs/load-balancing-proxy/ Just set up HAProxy,

Re: Java Riak client can't handle a Riak node failure?

Hi Dmitri, well...we solved our problem to our satisfaction but it turned out to be something unexpected. The keys were two properties mentioned in a blog post on "configuring Riak’s oft-subtle behavioral characteristics": http://basho.com/posts/technical/riaks-config-behaviors-part-4/