riak-client 2.3.0 → 2.3.1

data/lib/riak/stamp.rb

@@ -1,77 +1,77 @@
-require 'riak/client'
-require 'riak/util/translation'
-require 'thread'
-
-module Riak
-  # Implements a client-side form of monotonically-increasing k-sorted
-  # unique identifiers.  These are useful for key generation if your
-  # data is time-sequential and needs to be sorted by key, perhaps in
-  # Riak Search. Inspired by Twitter's Snowflake project.
-  class Stamp
-    attr_reader :client
-
-    CLIENT_ID_MASK = (1 << 10) - 1
-    SEQUENCE_MASK = (1 << 12) - 1
-    TIMESTAMP_MASK = (1 << 41) - 1
-    SEQUENCE_SHIFT = 10
-    TIMESTAMP_SHIFT = 22
-
-    # @param [Client] client a {Riak::Client} which will be used for
-    #   the "worker ID" component of the stamp.
-    # @see Client#stamp
-    def initialize(client)
-      @client = client
-      @mutex = Mutex.new
-      @timestamp = time_gen
-      @sequence = 0
-    end
-
-    # Generates a k-sorted unique ID for use as a key or other
-    # disambiguation purposes.
-    def next
-      @mutex.synchronize do
-        now = time_gen
-        if @timestamp == now
-          @sequence = (@sequence + 1) & SEQUENCE_MASK
-          now = wait_for_next_ms(@timestamp) if @sequence == 0
-        else
-          @sequence = 0
-        end
-
-        raise BackwardsClockError.new(@timestamp - now) if now < @timestamp
-
-        @timestamp = now
-        @timestamp << TIMESTAMP_SHIFT | @sequence << SEQUENCE_SHIFT | client_id
-      end
-    end
-
-    private
-    def client_id
-      case id = @client.client_id
-      when Integer
-        id & CLIENT_ID_MASK
-      else
-        id.hash & CLIENT_ID_MASK
-      end
-    end
-
-    def time_gen
-      (Time.now.to_f * 1000).floor & TIMESTAMP_MASK
-    end
-
-    def wait_for_next_ms(start)
-      now = time_gen
-      now = time_gen while now <= start
-      now
-    end
-  end
-
-  # Raised when calling {Stamp#next} and NTP or some other external
-  # event has moved the system clock backwards.
-  class BackwardsClockError < StandardError
-    include Util::Translation
-    def initialize(delay)
-      super t('backwards_clock', :delay => delay)
-    end
-  end
-end
+require 'riak/client'
+require 'riak/util/translation'
+require 'thread'
+
+module Riak
+  # Implements a client-side form of monotonically-increasing k-sorted
+  # unique identifiers.  These are useful for key generation if your
+  # data is time-sequential and needs to be sorted by key, perhaps in
+  # Riak Search. Inspired by Twitter's Snowflake project.
+  class Stamp
+    attr_reader :client
+
+    CLIENT_ID_MASK = (1 << 10) - 1
+    SEQUENCE_MASK = (1 << 12) - 1
+    TIMESTAMP_MASK = (1 << 41) - 1
+    SEQUENCE_SHIFT = 10
+    TIMESTAMP_SHIFT = 22
+
+    # @param [Client] client a {Riak::Client} which will be used for
+    #   the "worker ID" component of the stamp.
+    # @see Client#stamp
+    def initialize(client)
+      @client = client
+      @mutex = Mutex.new
+      @timestamp = time_gen
+      @sequence = 0
+    end
+
+    # Generates a k-sorted unique ID for use as a key or other
+    # disambiguation purposes.
+    def next
+      @mutex.synchronize do
+        now = time_gen
+        if @timestamp == now
+          @sequence = (@sequence + 1) & SEQUENCE_MASK
+          now = wait_for_next_ms(@timestamp) if @sequence == 0
+        else
+          @sequence = 0
+        end
+
+        raise BackwardsClockError.new(@timestamp - now) if now < @timestamp
+
+        @timestamp = now
+        @timestamp << TIMESTAMP_SHIFT | @sequence << SEQUENCE_SHIFT | client_id
+      end
+    end
+
+    private
+    def client_id
+      case id = @client.client_id
+      when Integer
+        id & CLIENT_ID_MASK
+      else
+        id.hash & CLIENT_ID_MASK
+      end
+    end
+
+    def time_gen
+      (Time.now.to_f * 1000).floor & TIMESTAMP_MASK
+    end
+
+    def wait_for_next_ms(start)
+      now = time_gen
+      now = time_gen while now <= start
+      now
+    end
+  end
+
+  # Raised when calling {Stamp#next} and NTP or some other external
+  # event has moved the system clock backwards.
+  class BackwardsClockError < StandardError
+    include Util::Translation
+    def initialize(delay)
+      super t('backwards_clock', :delay => delay)
+    end
+  end
+end

data/lib/riak/util/tcp_socket_extensions.rb

@@ -1,58 +1,58 @@
-require 'time'
-require 'timeout'
-require 'socket'
-
-# Borrowed from Webrat and Selenium client, watches for TCP port
-# liveness of the spawned server.
-# @private
-class TCPSocket
-  def self.wait_for_service(options)
-    verbose_wait until listening_service?(options)
-  end
-
-  def self.wait_for_service_termination(options)
-    verbose_wait while listening_service?(options)
-  end
-
-  def self.listening_service?(options)
-    Timeout::timeout(options[:timeout] || 20) do
-      begin
-        socket = TCPSocket.new(options[:host], options[:port])
-        socket.close unless socket.nil?
-        true
-      rescue Errno::ECONNREFUSED,
-        Errno::EBADF           # Windows
-        false
-      end
-    end
-  end
-
-  def self.verbose_wait
-    # Removed the puts call so as not to clutter up test output.
-    sleep 2
-  end
-
-  def self.wait_for_service_with_timeout(options)
-    start_time = Time.now
-
-    until listening_service?(options)
-      verbose_wait
-
-      if options[:timeout] && (Time.now > start_time + options[:timeout])
-        raise SocketError.new("Socket did not open within #{options[:timeout]} seconds")
-      end
-    end
-  end
-
-  def self.wait_for_service_termination_with_timeout(options)
-    start_time = Time.now
-
-    while listening_service?(options)
-      verbose_wait
-
-      if options[:timeout] && (Time.now > start_time + options[:timeout])
-        raise SocketError.new("Socket did not terminate within #{options[:timeout]} seconds")
-      end
-    end
-  end
-end
+require 'time'
+require 'timeout'
+require 'socket'
+
+# Borrowed from Webrat and Selenium client, watches for TCP port
+# liveness of the spawned server.
+# @private
+class TCPSocket
+  def self.wait_for_service(options)
+    verbose_wait until listening_service?(options)
+  end
+
+  def self.wait_for_service_termination(options)
+    verbose_wait while listening_service?(options)
+  end
+
+  def self.listening_service?(options)
+    Timeout::timeout(options[:timeout] || 20) do
+      begin
+        socket = TCPSocket.new(options[:host], options[:port])
+        socket.close unless socket.nil?
+        true
+      rescue Errno::ECONNREFUSED,
+        Errno::EBADF           # Windows
+        false
+      end
+    end
+  end
+
+  def self.verbose_wait
+    # Removed the puts call so as not to clutter up test output.
+    sleep 2
+  end
+
+  def self.wait_for_service_with_timeout(options)
+    start_time = Time.now
+
+    until listening_service?(options)
+      verbose_wait
+
+      if options[:timeout] && (Time.now > start_time + options[:timeout])
+        raise SocketError.new("Socket did not open within #{options[:timeout]} seconds")
+      end
+    end
+  end
+
+  def self.wait_for_service_termination_with_timeout(options)
+    start_time = Time.now
+
+    while listening_service?(options)
+      verbose_wait
+
+      if options[:timeout] && (Time.now > start_time + options[:timeout])
+        raise SocketError.new("Socket did not terminate within #{options[:timeout]} seconds")
+      end
+    end
+  end
+end

data/lib/riak/version.rb

@@ -1,3 +1,3 @@
 module Riak
-  VERSION = "2.3.0"
+  VERSION = "2.3.1"
 end

data/spec/failover/failover.rb

@@ -1,59 +1,59 @@
-$LOAD_PATH.unshift File.expand_path(File.dirname(__FILE__) + '/../../lib')
-require 'riak'
-
-# This is not a formal spec yet. It's designed to be run agains a local dev
-# cluster while you bring nodes up and down.
-[
-  {:protocol => 'pbc', :protobuffs_backend => :Beefcake},
-  {:protocol => 'http', :http_backend => :NetHTTP},
-  {:protocol => 'http', :http_backend => :Excon}
-].each do |opts|
-  @client = Riak::Client.new(
-    {
-      :nodes => (1..3).map { |i|
-        {
-          :http_port => 8090 + i,
-          :pb_port => 8080 + i
-        }
-      }
-    }.merge(opts)
-  )
-
-  errors = []
-  p opts
-
-  n = 10
-  c = 1000
-
-  (0...n).map do |t|
-    Thread.new do
-      # Generate a stream of put reqs. Put a . for each success, an X for
-      # each failure.
-      c.times do |i|
-        begin
-          o = @client['test'].new("#{t}:#{i}")
-          o.content_type = 'text/plain'
-          o.data = i.to_s
-          o.store
-          o2 = @client['test'].get("#{t}:#{i}")
-          o2.data == i.to_s or raise "wrong data"
-          print '.'
-        rescue => e
-          print 'X'
-          errors << e
-        end
-      end
-    end
-  end.each do |thread|
-    thread.join
-  end
-
-  # Put errors
-  puts
-  errors.each do |e|
-    puts e.inspect
-    puts e.backtrace.map { |x| "  #{x}" }.join("\n")
-  end
-
-  puts "\n\n"
-end
+$LOAD_PATH.unshift File.expand_path(File.dirname(__FILE__) + '/../../lib')
+require 'riak'
+
+# This is not a formal spec yet. It's designed to be run agains a local dev
+# cluster while you bring nodes up and down.
+[
+  {:protocol => 'pbc', :protobuffs_backend => :Beefcake},
+  {:protocol => 'http', :http_backend => :NetHTTP},
+  {:protocol => 'http', :http_backend => :Excon}
+].each do |opts|
+  @client = Riak::Client.new(
+    {
+      :nodes => (1..3).map { |i|
+        {
+          :http_port => 8090 + i,
+          :pb_port => 8080 + i
+        }
+      }
+    }.merge(opts)
+  )
+
+  errors = []
+  p opts
+
+  n = 10
+  c = 1000
+
+  (0...n).map do |t|
+    Thread.new do
+      # Generate a stream of put reqs. Put a . for each success, an X for
+      # each failure.
+      c.times do |i|
+        begin
+          o = @client['test'].new("#{t}:#{i}")
+          o.content_type = 'text/plain'
+          o.data = i.to_s
+          o.store
+          o2 = @client['test'].get("#{t}:#{i}")
+          o2.data == i.to_s or raise "wrong data"
+          print '.'
+        rescue => e
+          print 'X'
+          errors << e
+        end
+      end
+    end
+  end.each do |thread|
+    thread.join
+  end
+
+  # Put errors
+  puts
+  errors.each do |e|
+    puts e.inspect
+    puts e.backtrace.map { |x| "  #{x}" }.join("\n")
+  end
+
+  puts "\n\n"
+end

data/spec/fixtures/bitcask.txt

@@ -1,25 +1,25 @@
-Bitcask is an Erlang application that provides an API for storing and retrieving key/value data into a log-structured hash table that provides very fast access. The design owes a lot to the principles found in log-structured file systems and draws inspiration from a number of designs that involve log file merging.
-
-Strengths
-Low latency per item read or written
-This is due to the write-once, append-only nature of the Bitcask database files. High throughput, especially when writing an incoming stream of random items Because the data being written doesn't need to be ordered on disk and because the log structured design allows for minimal disk head movement during writes these operations generally saturate the I/O and disk bandwidth.
-
-Ability to handle datasets larger than RAM w/o degradation
-Because access to data in Bitcask is direct lookup from an in-memory hash table finding data on disk is very efficient, even when data sets are very large.
-
-Single Seek to Retrieve Any Value
-Bitcask's in-memory hash-table of keys point directly to locations on disk where the data lives. Bitcask never uses more than one disk seek to read a value and sometimes, due to file-system caching done by the operating system, even that isn't necessary.
-
-Predictable Lookup and Insert Performance
-As you might expect from the description above, read operations have a fixed, predictable behavior. What you might not expect is that this is also true for writes. Write operations are at most a seek to the end of the current file open writing and an append to that file.
-
-Fast, bounded Crash Recovery
-Due to the append-only write once nature of Bitcask files, recovery is easy and fast. The only items that might be lost are partially written records at the tail of the file last opened for writes. Recovery need only review the last record or two written and verify CRC data to ensure that the data is consistent.
-
-Easy Backup
-In most systems backup can be very complicated but here again Bitcask simplifies this process due to its append-only write once disk format. Any utility that archives or copies files in disk-block order will properly backup or copy a Bitcask database.
-
-Weakness
-Keys Must Fit In Memory
-Bitcask keeps all keys in memory at all times, this means that your system must have enough memory to contain your entire keyspace with room for other operational components and operating system resident filesystem buffer space.
-
+Bitcask is an Erlang application that provides an API for storing and retrieving key/value data into a log-structured hash table that provides very fast access. The design owes a lot to the principles found in log-structured file systems and draws inspiration from a number of designs that involve log file merging.
+
+Strengths
+Low latency per item read or written
+This is due to the write-once, append-only nature of the Bitcask database files. High throughput, especially when writing an incoming stream of random items Because the data being written doesn't need to be ordered on disk and because the log structured design allows for minimal disk head movement during writes these operations generally saturate the I/O and disk bandwidth.
+
+Ability to handle datasets larger than RAM w/o degradation
+Because access to data in Bitcask is direct lookup from an in-memory hash table finding data on disk is very efficient, even when data sets are very large.
+
+Single Seek to Retrieve Any Value
+Bitcask's in-memory hash-table of keys point directly to locations on disk where the data lives. Bitcask never uses more than one disk seek to read a value and sometimes, due to file-system caching done by the operating system, even that isn't necessary.
+
+Predictable Lookup and Insert Performance
+As you might expect from the description above, read operations have a fixed, predictable behavior. What you might not expect is that this is also true for writes. Write operations are at most a seek to the end of the current file open writing and an append to that file.
+
+Fast, bounded Crash Recovery
+Due to the append-only write once nature of Bitcask files, recovery is easy and fast. The only items that might be lost are partially written records at the tail of the file last opened for writes. Recovery need only review the last record or two written and verify CRC data to ensure that the data is consistent.
+
+Easy Backup
+In most systems backup can be very complicated but here again Bitcask simplifies this process due to its append-only write once disk format. Any utility that archives or copies files in disk-block order will properly backup or copy a Bitcask database.
+
+Weakness
+Keys Must Fit In Memory
+Bitcask keeps all keys in memory at all times, this means that your system must have enough memory to contain your entire keyspace with room for other operational components and operating system resident filesystem buffer space.
+

data/spec/fixtures/multipart-basic-conflict.txt

@@ -1,15 +1,15 @@
---8XZD3w6ttFTHIz6LCmhVxn9Ex0K
-Content-Type: text/plain
-Link: </buckets/test>; rel="up"
-Etag: 2baUwethOoLrVkwnMqzBRW
-Last-Modified: Mon, 15 Oct 2012 19:36:06 GMT
-
-bar
---8XZD3w6ttFTHIz6LCmhVxn9Ex0K
-Content-Type: text/plain
-Link: </buckets/test>; rel="up"
-Etag: 6NtlHf8Lc3TEcCTKOVqEkl
-Last-Modified: Mon, 15 Oct 2012 19:35:57 GMT
-
-foo
---8XZD3w6ttFTHIz6LCmhVxn9Ex0K--
+--8XZD3w6ttFTHIz6LCmhVxn9Ex0K
+Content-Type: text/plain
+Link: </buckets/test>; rel="up"
+Etag: 2baUwethOoLrVkwnMqzBRW
+Last-Modified: Mon, 15 Oct 2012 19:36:06 GMT
+
+bar
+--8XZD3w6ttFTHIz6LCmhVxn9Ex0K
+Content-Type: text/plain
+Link: </buckets/test>; rel="up"
+Etag: 6NtlHf8Lc3TEcCTKOVqEkl
+Last-Modified: Mon, 15 Oct 2012 19:35:57 GMT
+
+foo
+--8XZD3w6ttFTHIz6LCmhVxn9Ex0K--