Sean and All - In case it helps, the problem manifested on riak 0.14.0 on Mac OS but not on an Ubuntu VM.
The most recent version available for download at http://downloads.basho.com/riak/CURRENT/ for Mac OS was 0.14.0, so that's what I'm using. I realize that would have been helpful information I could have provided before, and apologize for not mentioning it -- I forgot that I had to use an earlier version to run it on the Mac. Are there any plans to provide more recent versions for the Mac? Or can I build from one of the other packages? Also, Is there a way within Riak::Client or somewhere else in the ruby riak client gem or riak executables or config files to get the server version number and possibly OS information? I do see this: { % }: ls -1 releases 6.Jun.11 12.18 0.14.0 start_erl.data ...is this the best way? Thanks, Keith On Jun 4, 2011, at 11:26 AM, Sean Cribbs wrote: > I already have an issue open on the tracker to deal with some of the client > semantics changes (https://github.com/seancribbs/ripple/issues/166); it might > be broken out into separate issues so it can be completed. > > Sean Cribbs <[email protected]> > Developer Advocate > Basho Technologies, Inc. > http://basho.com/ > > On Jun 3, 2011, at 6:19 PM, Andrew Thompson wrote: > >> On Fri, Jun 03, 2011 at 06:08:06PM -0400, Keith Bennett wrote: >>> Aphyr & Andrew - >>> >>> Thanks for your responses. I'm trying to wrap my head around the issues >>> you raised, and I must confess it's difficult. Anyway, some questions for >>> you... >>> >>> On Jun 3, 2011, at 5:12 PM, Andrew Thompson wrote: >>> >>>> On Fri, Jun 03, 2011 at 02:00:23PM -0700, Aphyr wrote: >>>>> Riak can't use the vclock for conflict resolution on a fresh object, >>>>> i.e. one without a vclock. Deletes are writes. You should use get or >>>>> reload before writing to help Riak sequence your writes correctly. >>> >>> If the caller doesn't have a handle to the RObject in the Ruby framework, >>> or the metadata of an HTTP response, but is only accessing the data by >>> bucket and key values, is there any way to use reload? And if the object >>> has been deleted is there any way to use get? >>> >>>>> >>>>> On top of this, Riak has some weirdness around very quick sequences >>>>> of deletes/writes due, IIRC, to deletes not being tagged with a >>>>> vector clock. I... think... this will be addressed in an upcoming >>>>> release. >>> >>> I tried inserting a 20 second pause between each read/write, but there was >>> no change in the behavior. Should it be longer than that? >> >> This is scary, it should not be possible to trigger this behaviour with >> such a large gap. Even 10ms was enough to prevent it in my testing. >>> >>>>> >>>> >>>> Ah, my favorite bug. This is indeed mostly solved on master by exposing >>>> the vclocks for tombstones so they can be cleanly overwritten by the new >>>> object rather than merged into a frankenobject that has the metadata of >>>> the tombstone but the value of the new object (which is then subject to >>>> real deletion). >>>> >>>> So the fix for the issue was to add a new type of return value for a get >>>> that finds a tombstone, {error, {deleted, Vclock}} instead of always >>>> returning {error, notfound} on a true notfound or when a tombstone is >>>> encountered. >>>> >>> >>> That sounds like exactly what I need. Can I simulate that fix in my Ruby >>> code? Any pointers about that? Any chance we could get that into the Ruby >>> client? I'd be willing to put a little effort into that, but I don't >>> really understand the issues well enough yet. >> >> I suspect we will want to update the clients to support this, but I >> don't know of a specific plan to do so yet. I don't know the details of >> the ruby client enough (or at all) to advise on making changes to it. >> >>> >>>> An example of how to safely delete for all 3 APIs can be found at >>>> >>>> https://gist.github.com/965376 >>>> >>>> Note the new deletedvclock option. The REST API will always use this >>>> option on gets and will return a X-Riak-Vclock header along with any 404 >>>> that is actually a tombstone. >>>> >>>> Some further reading can be found here: >>>> >>>> https://issues.basho.com/show_bug.cgi?id=260 >>>> https://issues.basho.com/show_bug.cgi?id=555 >>>> >>>> So, long story short; either upgrade to master and use the deletedvclock >>>> option or avoid doing rapid put/delete/put cycles. >>> >>> You're suggesting I use mercurial to pull down the HEAD and use that, right? >>> >> >> git, not mercurial. I don't think we maintain the bitbucket repos >> anymore, everything has moved to github. >> >> Andrew >> >> _______________________________________________ >> riak-users mailing list >> [email protected] >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
