<div dir="ltr"><div><div>Matthew,<br><br></div>I did some testing with your code and I was able to reproduce what you were seeing. I would occasionally see an error similar to the following:<br><br>    Failed to fetch item 460 err Object not found<br>
<br>This behavior is a result of the trade-offs of using an eventually consistent database like Riak. It is not the case that your inserts are failing to write or the data is being lost, but what is actually happening is that the quick read after writing with the default request options does not provide any guarantee that you will read your writes. So basically when you make the read, the replicas that are responding to your request have not seen the latest value yet and so you end up with "Not Found" as the response. If you did another read attempt for one of those objects reported missing, it would succeed because Riak's read-repair would have kicked in to make sure each replica has the value. To increase the likelihood of reading your writes you should set the optional request parameters pr and pw to ensure that all of the primary replicas are available prior to performing a read or write request. I altered your code to use those options and put the updates in a gist [1] (it's my first stab at Go so my changes may not be very idiomatic). Additionally I changed to riak driver so that NotFoundOk was false instead of true. With these changes I was able to run the test 50 times in a row with no errors where previously I would see at least one error every 10 iterations or so. Hope that helps.<br>
<br>[1] : <a href="https://gist.github.com/kellymclaughlin/6041109">https://gist.github.com/kellymclaughlin/6041109</a><br><br></div>Kelly<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 17, 2013 at 4:07 PM, Matthew Dawson <span dir="ltr"><<a href="mailto:matthew@mjdsystems.ca" target="_blank">matthew@mjdsystems.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On July 17, 2013 08:45:01 AM Kelly McLaughlin wrote:<br>
> Matthew,<br>
><br>
> I find it really surprising that you don't see any difference in behavior<br>
> when you set delete_mode to keep. I think it would be helpful if you could<br>
> outline your specific setup and give the steps to reproduce what you're<br>
> seeing to be able to make a determination if this represents a bug or not.<br>
> Thanks.<br>
><br>
> Kelly<br>
</div>Hi Kelly,<br>
<br>
Sure, no problem.  Hardware wise, I have:<br>
 - An AMD Phenom II X6 Desktop with 16G memory, and a HDD with an SSD cache.<br>
 - An Intel Ivy Bridge Dual Core (+HT) Laptop with 16G memory and SSD.<br>
Both have lots of free memory + disk space for running my tests, and my<br>
Desktop never seems to be IO bound.  Both machines are connected over Ethernet<br>
on the same LAN.<br>
<br>
On top of that hardware, both are running two instances of Riak each, all<br>
forming one 4 node cluster.  I'm using the default ring size of 64.  I've also<br>
upgraded all the nodes to the latest release, 1.4, using the 1.4 tag from Git.<br>
I'm not using this to seriously benchmark Riak, so I don't think this setup<br>
should cause any issues.  I'm also going to setup a really cluster for<br>
production use, so ring size is not a concern.<br>
Each Riak instance uses LevelDB as the datastore, Riak Search is disabled.<br>
I'm using Riak's PB API for access, and I've bumped up the backlog parameter<br>
to 1024 for now.  Originally my program would connect to a single node, but<br>
recently I've been playing with HAProxy locally, and now I use that to connect<br>
to all four instances.  The problem existed before I implemented HAProxy.<br>
Riak Control is also enabled on one node per computer.<br>
<br>
For my application, it effectively stores in Riak two pieces of information.<br>
First it stores a list of keys associated with an object, and then stores an<br>
individual item at each key.  I limit the number of keys to 10000 per object.<br>
<br>
For my test suite, I automatically clean up after each test by listing all the<br>
keys associated with a bucket, and then delete each key individually.  I only<br>
store items in two buckets, so this cleans the slate before each run.<br>
<br>
The test that has the high chance of failing is testing how the system deals<br>
with inserting 10000 items against one object.  The key list remains below 1M.<br>
Occasionally I see other tests fail, but I think this one fails more often as<br>
it stresses the entire system the most.  If I stop the automatic cleanup, the<br>
not found key is also not findable by Curl either.<br>
<br>
Before posting, I would delete and insert keys, without using a vclock.  I had<br>
figured this was safe as I ran with allow_mult=true on both buckets, and I<br>
implemented conflict resolution first.  As suggested on this list, I now have<br>
the 10000 item test suite use vclocks from start to finish.  However, I still<br>
see this behaviour.<br>
<br>
I've attached a program (written in go as that is what I'm using) to this<br>
email which triggers the behaviour.  As far as I understand Riak, it is<br>
properly fetching vclocks whenever possible.  The library I'm using (located<br>
at: <a href="http://github.com/tpjg/goriakpbc" target="_blank">github.com/tpjg/goriakpbc</a> ) was just recently updated to ensure that<br>
vclocks are fetched, even if the item is deleted.  I am using an up to date<br>
version of the library.  The program is acts similarly to my app, but paired<br>
down as far as possible.  Note that this behaviour is unpredictable, and this<br>
program will sometimes execute fine.<br>
I only tested this program against the default delete_mode setting.  Also,<br>
using HAProxy seems to trigger the issue far more readily, but it happens fine<br>
without it.<br>
<br>
<br>
If there is any other information I can provide to help, let me know.<br>
<br>
Thanks,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Matthew</font></span><br>_______________________________________________<br>
riak-users mailing list<br>
<a href="mailto:riak-users@lists.basho.com">riak-users@lists.basho.com</a><br>
<a href="http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com" target="_blank">http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com</a><br>
<br></blockquote></div><br></div>