beetle 3.5.0 → 3.5.4

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: beetle
 version: !ruby/object:Gem::Version
-  version: 3.5.0
+  version: 3.5.4
 platform: ruby
 authors:
 - Stefan Kaes
@@ -12,7 +12,7 @@ authors:
 autorequire:
 bindir: bin
 cert_chain: []
-date: 2021-01-22 00:00:00.000000000 Z
+date: 2022-08-30 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bunny
@@ -35,6 +35,9 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: 4.2.1
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '5.0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
@@ -42,6 +45,9 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: 4.2.1
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '5.0'
 - !ruby/object:Gem::Dependency
   name: hiredis
   requirement: !ruby/object:Gem::Requirement
@@ -118,14 +124,14 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 2.4.0
+        version: 8.0.0
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 2.4.0
+        version: 8.0.0
 - !ruby/object:Gem::Dependency
   name: daemon_controller
   requirement: !ruby/object:Gem::Requirement
@@ -188,28 +194,28 @@ dependencies:
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 1.3.0
+        version: '1.14'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 1.3.0
+        version: '1.14'
 - !ruby/object:Gem::Dependency
   name: mysql2
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.4.4
+        version: '0.5'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: 0.4.4
+        version: '0.5'
 - !ruby/object:Gem::Dependency
   name: rake
   requirement: !ruby/object:Gem::Requirement
@@ -225,49 +231,91 @@ dependencies:
       - !ruby/object:Gem::Version
         version: '13.0'
 - !ruby/object:Gem::Dependency
-  name: rdoc
+  name: simplecov
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '4.0'
+        version: '0.15'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '4.0'
+        version: '0.15'
 - !ruby/object:Gem::Dependency
-  name: simplecov
+  name: webmock
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '0.15'
+        version: '3.0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - "~>"
       - !ruby/object:Gem::Version
-        version: '0.15'
+        version: '3.0'
 - !ruby/object:Gem::Dependency
-  name: webmock
+  name: websocket-eventmachine-client
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '3.0'
+        version: '0'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - "~>"
+    - - ">="
       - !ruby/object:Gem::Version
-        version: '3.0'
+        version: '0'
 - !ruby/object:Gem::Dependency
-  name: websocket-eventmachine-client
+  name: yard
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: redcarpet
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: github-markup
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: byebug
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ">="
@@ -285,19 +333,11 @@ email: opensource@xing.com
 executables: []
 extensions: []
 extra_rdoc_files:
-- RELEASE_NOTES.rdoc
-- examples/README.rdoc
-- REDIS_AUTO_FAILOVER.rdoc
-- README.rdoc
 - MIT-LICENSE
 files:
 - MIT-LICENSE
-- README.rdoc
-- REDIS_AUTO_FAILOVER.rdoc
-- RELEASE_NOTES.rdoc
 - Rakefile
 - beetle.gemspec
-- examples/README.rdoc
 - examples/attempts.rb
 - examples/attempts_with_dead_letter_and_exponential_backoff.rb
 - examples/attempts_with_exponential_backoff.rb
@@ -378,24 +418,24 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: 1.3.7
 requirements: []
-rubygems_version: 3.0.8
+rubygems_version: 3.3.19
 signing_key:
 specification_version: 3
 summary: High Availability AMQP Messaging with Redundant Queues
 test_files:
-- test/beetle_test.rb
-- test/beetle/client_test.rb
 - test/beetle/amqp_gem_behavior_test.rb
-- test/beetle/deduplication_store_test.rb
-- test/beetle/queue_properties_test.rb
-- test/beetle/handler_test.rb
+- test/beetle/base_test.rb
 - test/beetle/beetle_test.rb
+- test/beetle/client_test.rb
 - test/beetle/configuration_test.rb
-- test/beetle/subscriber_test.rb
+- test/beetle/deduplication_store_test.rb
+- test/beetle/handler_test.rb
 - test/beetle/message/settings_test.rb
-- test/beetle/redis_ext_test.rb
 - test/beetle/message_test.rb
 - test/beetle/publisher_test.rb
+- test/beetle/queue_properties_test.rb
 - test/beetle/r_c_test.rb
-- test/beetle/base_test.rb
+- test/beetle/redis_ext_test.rb
+- test/beetle/subscriber_test.rb
+- test/beetle_test.rb
 - test/test_helper.rb

data/README.rdoc

@@ -1,233 +0,0 @@
-= Beetle
-
-High Availability AMQP Messaging with Redundant Queues
-
-== About
-
-Beetle grew out of a project to improve an existing ActiveMQ based messaging
-infrastructure. It offers the following features:
-
-* High Availability (by using multiple message broker instances)
-* Redundancy (by replicating queues)
-* Simple client API (by encapsulating the publishing/ deduplication logic)
-
-More information can be found on the {project website}[http://xing.github.com/beetle].
-
-== Release notes
-
-See {RELEASE_NOTES.rdoc}[https://github.com/xing/beetle/blob/master/RELEASE_NOTES.rdoc]
-
-== Usage
-
-=== Configuration
-    # configure machines
-
-    Beetle.config do |config|
-      config.servers = "broker1:5672, broker2:5672"
-      config.redis_server = "redis1:6379"
-    end
-
-    # instantiate a beetle client
-
-    b = Beetle::Client.new
-
-    # configure exchanges, queues, bindings, messages and handlers
-
-    b.configure do
-      queue :test
-      message :test
-      handler(:test) { |message| puts message.data }
-    end
-
-=== Publishing
-    b.publish :test, "I'm a test message"
-
-=== Subscribing
-    b.listen_queues
-
-=== Examples
-
-Beetle ships with a number of {example scripts}[http://github.com/xing/beetle/tree/master/examples/].
-
-The top level Rakefile comes with targets to start several RabbitMQ and redis instances
-locally. Make sure the corresponding binaries are in your search path. Open four new shell
-windows and execute the following commands:
-
-    rake rabbit:start1
-    rake rabbit:start2
-    rake redis:start:master
-    rake redis:start:slave
-
-== Prerequisites
-
-To set up a redundant messaging system you will need
-* at least 2 AMQP servers (we use {RabbitMQ}[http://www.rabbitmq.com/])
-* at least one {Redis}[http://github.com/antirez/redis] server (better are two in a master/slave setup, see REDIS_AUTO_FAILOVER.rdoc)
-
-== Test environment
-
-For testing purposes, you will need a MySQL database with the database
-`beetle_test` created. This is needed to test special cases in which
-Beetle handles the connection with ActiveRecord:
-
-     mysql -e 'create database beetle_test;'
-
-You also need a Redis instance running. The default configuration of Redis will work:
-
-    redis-server
-
-If you want to run the integration tests you need GO installed and you
-will need to build the beetle binary. We provide a Makefile for this
-purpose, so simply running
-
-    make
-
-should suffice.
-
-== Gem Dependencies
-
-At runtime, Beetle will use
-* {bunny}[http://github.com/ruby-amqp/bunny]
-* {redis}[http://github.com/redis/redis-rb]
-* {amqp}[http://github.com/ruby-amqp/amqp]
-  (which is based on {eventmachine}[http://github.com/eventmachine/eventmachine])
-* {daemons}[http://daemons.rubyforge.org/]
-* {activesupport}[https://github.com/rails/rails/tree/master/activesupport]
-
-For development, you'll need
-* {mocha}[http://github.com/floehopper/mocha]
-* {cucumber}[http://github.com/aslakhellesoy/cucumber]
-* {daemon_controller}[http://github.com/FooBarWidget/daemon_controller]
-* {consul}[https://www.consul.io/downloads.html]
-
-For tests, you'll need
-* {activerecord}[https://github.com/rails/rails/tree/master/activerecord]
-* {mysql2}[https://github.com/brianmario/mysql2/]
-
-Dependencies are managed by bundler.
-
-== Authors
-
-{Stefan Kaes}[http://github.com/skaes],
-{Pascal Friederich}[http://github.com/paukul],
-{Ali Jelveh}[http://github.com/dudemeister],
-{Bjoern Rochel}[http://github.com/bjro] and
-{Sebastian Roebke}[http://github.com/boosty].
-
-You can find out more about our work on our {dev blog}[http://devblog.xing.com].
-
-Copyright (c) 2010-2019 {XING AG}[http://www.xing.com/]
-
-Released under the MIT license. For full details see MIT-LICENSE included in this
-distribution.
-
-== Contributing
-
-1. Fork it
-2. Create your feature branch (`git checkout -b my-new-feature`)
-3. Hack along and test your code.
-4. Commit your changes (`git commit -am 'Add some feature'`)
-5. Push to the branch (`git push origin my-new-feature`)
-6. Create new Pull Request
-
-Don't increase the gem version in your pull requests. It will be done after merging the request,
-to allow merging of pull requests in a flexible order.
-
-== Compiling beetle and running tests
-
-In order to execute the unit tests, you need Ruby, a running rabbitmq server, a running
-redis-server, a running mysql server and a runnning consul server.
-
-In addition, beetle ships with a cucumber feature to test the automatic redis failover as
-an integration test. For this you need a recent Go installation in order to compile the
-beetle go binary. Just invoke `make` in the top level directory.
-
-There are two ways to start the required test dependencies: using `docker-compose` or
-starting the services manually.
-
-=== Testing with docker-compose
-
-Open a separate terminal window and run
-
-     docker-compose pull
-
-followed by
-
-     docker-compose up
-
-This will start mysql, two redis servers, two RabbitMQ instances and a single consul
-development node.
-
-Note: make sure to wait until all services are properly started.
-
-
-== Tesing with  locally installed services
-
-The top level Rakefile comes with targets to start several RabbitMQ instances locally.
-Make sure the corresponding binaries are in your search path. Open three shell windows and
-execute the following command:
-
-    rake rabbit:start1
-
-and
-
-   rake redis:start:master
-
-as well as
-
-   rake consul:start
-
-Then you can run the cucumber feature by running:
-
-    cucumber
-
-or
-
-    rake cucumber
-
-Note: Cucumber will automatically run after the unit tests when you run `rake` without
-arguments.
-
-
-== How to release a new gem version
-
-Update RELEASE_NOTES.rdoc!
-
-We use {semantic versioning}[http://semver.org/] and create a git tag
-for each release.
-
-Edit `lib/beetle/version.rb` and
-`go/src/github.com/xing/beetle/version.go` to set the new version
-number (`Major.Minor.Patch`).
-
-In short (see {semver.org}[http://semver.org] for details):
-
-* *Major* version MUST be incremented if any backwards incompatible changes
-  are introduced to the public API.
-* *Minor* version MUST be incremented if new, backwards compatible functionality
-  is introduced to the public API. It MUST be incremented if any public API
-  functionality is marked as deprecated.
-* *Patch* version MUST be incremented if only backwards compatible bug fixes
-  are introduced.
-
-Then use `rake release` which will create the git tag and upload the
-gem to github.com:
-
-    bundle exec rake release
-
-The generated gem is located in the `pkg/` directory.
-
-In order to build go binaries and upload the docker container with the
-beetle GO binary to docker hub, run
-
-    make release
-
-This will upload the go binaries to https://github.com/xing/beetle/
-and push the beetle container to
-https://hub.docker.com/r/xingarchitects/gobeetle/.
-
-Run
-
-    make tag push TAG=X.X.X
-
-to tag and push the container with a specific version number.

data/REDIS_AUTO_FAILOVER.rdoc

@@ -1,116 +0,0 @@
-= Automatic Redis Failover for Beetle
-
-== Introduction
-
-Redis is used as the persistence layer in the AMQP message deduplication
-process. Because it is such a critical piece in our infrastructure, it is
-essential that a failure of this service is as unlikely as possible. As our
-AMQP workers are working in a highly distributed manner, all accessing the same
-Redis server, a automatic failover to another Redis server has to be very
-defensive and ensure that every worker in the system will switch to the new
-server at the same time. If the new server would not get accepted from every
-worker, a switch would not be possible. This ensures that even in the case of a
-partitioned network it is impossible that two different workers use two
-different Redis servers for message deduplication.
-
-== Our goals
-
-* opt-in, no need to use the redis-failover solution
-* no single point of failure
-* automatic switch in case of redis-master failure
-* switch should not cause inconsistent data on the redis servers
-* workers should be able to determine the current redis-master without asking
-  another process (as long as the redis servers are working)
-
-== How it works
-
-To ensure consistency, a service (the Redis Configuration Server - RCS) is
-constantly checking the availability and configuration of the currently
-configured Redis master server. If this service detects that the Redis master
-is no longer available, it tries to find an alternative server (one of the
-slaves) which could be promoted to be the new Redis master.
-
-On every worker server runs another daemon, the Redis Configuration Client
-(RCC) which listens to messages sent by the RCS.
-
-If the RCS finds another potential Redis Master, it sends out a message to see
-if all known RCCs are still available (once again to eliminate the risk of a
-partitioned network) and if they agree to the master switch.
-
-If all RCCs have answered to that message, the RCS sends out a message which
-tells the RCCs to invalidate the current master.
-
-This happens by deleting the contents of a special file which is used
-by the workers to store the current Redis master (the content of that file is
-the hostname:port of the currently active Redis master). By doing that, it is
-ensured that no operations are done to the old Redis master server anymore, because the
-AMQP workers check this file's mtime and reads its contents in case that the
-file changed, before every Redis operation. When the file has been emptied, the
-RCCs respond to the "invalidate" message of the RCS. When all RCCs have
-responded, the RCS knows for sure that it is safe to switch the Redis master
-now. It sends a "reconfigure" message with the new Redis master hostname:port
-to the RCCs, which then write that value into their redis master file.
-
-Additionally, the RCS sends reconfigure messages with the current Redis master
-periodically, to allow new RCCs to pick up the current master. Plus it turns
-all other redis servers into slaves of the current master.
-
-=== Prerequisites
-
-* one redis-configuration-server process ("RCS", on one server), one redis-configuration-client process ("RCC") on every worker server
-* the RCS knows about all possible RCCs using a list of client ids
-* the RCS and RCCs exchange messages via a "system queue"
-
-=== Flow of actions
-
-* on startup, an RCC can consult its redis master file to determine the current master without the help of the RCS by checking that it's still a master (or wait for the periodic reconfigure message with the current master from the RCS)
-* when the RCS finds the master to be down, it will retry a couple of times before starting a reconfiguration round
-* the RCS sends all RCCs a "ping" message to check if every client is there and able to answer
-* the RCCs acknowledge via a "pong" message if they can confirm the current master to be unavailable
-* the RCS waits for *all* RCCs to reply via pong
-* the RCS tells all RCCs to stop using the master by sending an "invalidate" message
-* the RCCs acknowledge via an "invalidated" message if they can still confirm the current master to be unavailable
-* the RCS waits for *all* RCCs to acknowledge the invalidation
-* the RCS promotes the former slave to become the new master (by sending SLAVEOF no one)
-* the RCS sends a "reconfigure" message containing the new master to every RCC
-* the RCCs write the new master to their redis master file
-
-=== Configuration
-
-See Beetle::Configuration for setting redis configuration server and client options.
-
-Please note:
-Beetle::Configuration#redis_server must be a file path (not a redis host:port string) to use the redis failover. The RCS and RCCs store the current redis master in that file, and the handlers read from it.
-
-== How to use it
-
-This example uses two worker servers, identified by rcc-1 and rcc-2.
-
-Please note:
-All command line options can also be given as a yaml configuration file via the --config-file option.
-
-=== On one server
-
-Start the Redis Configuration Server:
-
-  beetle configuration_server --redis-servers redis-1:6379,redis-2:6379 --client-ids rcc-1,rcc-2
-
-Get help for server options:
-
-  beetle configuration_server -h
-
-=== On every worker server
-
-Start the Redis Configuration Client:
-
-On first worker server:
-
-  beetle configuration_client --client-id rcc-1
-
-On second worker server:
-
-  beetle configuration_client --client-id rcc-2
-
-Get help for client options:
-
-  beetle configuration_client -h