jiak.rb not correctly updating objects: X-Riak-ClientId issue?

Jay Doane jay.s.doane at gmail.com
Wed Jan 27 14:43:42 EST 2010


On Nov 5, 2009, at 12:46 PM, Bryan Fink wrote:

> On Thu, Nov 5, 2009 at 2:18 PM, francisco treacy
> <francisco.treacy at gmail.com> wrote:
>
>> 2. vclocks => sometimes extremely long (vastly outweighing the object
>> itself), or those were edge cases in my test scenarios?
>
> The tool you can use now is the X-Riak-ClientId header.  Just make
> each of your actors use a unique value for this header, and you'll see
> vclocks stay much smaller.

I noticed that the Python client had not yet had this functionality  
added, so I thought I would take a stab at it.  However, after I  
finished, I was testing it a bit and discovered that objects were not  
being updated correctly following the *second* PUT.

I wanted to see if I had introduced a bug with my implementation which  
followed closely the logic in jiak.rb, so I tested the ruby client,  
and saw the same unexpected behavior.

Here's an example using the jiak.rb

$ irb
irb(main):001:0> require 'jiak'
=> true
irb(main):002:0> jc = Riak::Client.new("127.0.0.1", 8098)
=> #<Riak::Client:0x1029238 @port=8098, @ip="127.0.0.1",  
@opts={"clientId"=>"3arpUQ=="}, @prefix="/jiak/">
irb(main):003:0> jc.list_bucket('b')
=> {"keys"=>[], "schema"=>{"read_mask"=>"*", "write_mask"=>"*",  
"required_fields"=>[], "allowed_fields"=>"*"}}
irb(main):004:0>  
jc.store({'bucket'=>'b','key'=>'k','links'=>[],'object'=>{'foo'=>0}})
=> {"bucket"=>"b", "lastmod"=>"Wed, 27 Jan 2010 19:28:30 GMT",  
"vclock"=>"a85hYGBgzGDKBVIsd1e9DMxgSmTMY2W4x3/1CF8WAA==",  
"vtag"=>"5RLV2q1b1Q6yWQ1WChGFW0", "links"=>[], "key"=>"k",  
"object"=>{"foo"=>0}}
irb(main):005:0>  
jc.store({'bucket'=>'b','key'=>'k','links'=>[],'object'=>{'foo'=>1}})
=> {"bucket"=>"b", "lastmod"=>"Wed, 27 Jan 2010 19:28:42 GMT",  
"vclock 
"=>"a85hYGBgymDKBVIsd1e9DMxgSmTMY2W4x3/1CB9EmK05ieF6tjhU4hVIIgsA",  
"vtag"=>"2nV8PqNGAmiRlo3DKegw3T", "links"=>[], "key"=>"k",  
"object"=>{"foo"=>1}}
irb(main):006:0>  
jc.store({'bucket'=>'b','key'=>'k','links'=>[],'object'=>{'foo'=>2}})
=> {"bucket"=>"b", "lastmod"=>"Wed, 27 Jan 2010 19:28:42 GMT",  
"vclock 
"=>"a85hYGBgymDKBVIsd1e9DMxgSmTMY2W4x3/1CB9EmK05ieF6tjhU4hVIIgsA",  
"vtag"=>"2nV8PqNGAmiRlo3DKegw3T", "links"=>[], "key"=>"k",  
"object"=>{"foo"=>1}}
irb(main):007:0>

Notice how object["foo"] remains 1 after the last update, which I  
expected would change to 2.

After deleting key "k" from the bucket, I tried again using the python  
client from tip, and saw the behavior I expected (that is, foo  
correctly updates each time.

jay at alu:~$ python
Python 2.6.4 (r264:75706, Dec 21 2009, 16:33:33)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import jiak
 >>> jc = jiak.Jiak('127.0.0.1', 8098, 'jiak')
 >>> jc.list_bucket('b')
{u'keys': [],
  u'schema': {u'allowed_fields': u'*',
              u'read_mask': u'*',
              u'required_fields': [],
              u'write_mask': u'*'}}
 >>> jc.store('b', 'k', {'foo':1})
{u'bucket': u'b',
  u'key': u'k',
  u'lastmod': u'Wed, 27 Jan 2010 19:11:35 GMT',
  u'links': [],
  u'object': {u'foo': 1},
  u'vclock': u'a85hYGBgzGDKBVIsrJ/+cGQwJTLmsTI85756hC8LAA==',
  u'vtag': u'4gi9WJeDnLOzHk4rInVV8i'}
 >>> jc.store('b', 'k', {'foo':2})
{u'bucket': u'b',
  u'key': u'k',
  u'lastmod': u'Wed, 27 Jan 2010 19:11:45 GMT',
  u'links': [],
  u'object': {u'foo': 2},
  u'vclock': u'a85hYGBgzmDKBVIsrJ/+cGQwJTLmsTI85756hA8qzKioMgUq/ 
BEhzNacxMjsfAxZIgsA',
  u'vtag': u'6M17caK2ZhwVvbez2LAOae'}
 >>> jc.store('b', 'k', {'foo':3})
{u'bucket': u'b',
  u'key': u'k',
  u'lastmod': u'Wed, 27 Jan 2010 19:11:49 GMT',
  u'links': [],
  u'object': {u'foo': 3},
  u'vclock': u'a85hYGBgzWDKBVIsrJ/ 
+ 
cGQwJTLmsTI85756hA8izNacxMjsfAwq8REhwcKoqDIFizDr1sNnocJfUYxh7WvzRZbIAgA 
=',
  u'vtag': u'TiCO4GLydhVLQCTVApIHs'}

I have also confirmed that this bug does *not* occur in the raw http  
interface or the erlang raw client, or even the /jiak http interface  
using curl.

Can anyone else confirm and/or explain this behavior?  The last thing  
I want to do is add buggy X-Riak-ClientId functionality to jiak.py.

Thanks,
Jay





More information about the riak-users mailing list