haredo 2.0.8 → 2.0.9

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 7f21bd9b2983e55f7916fc5060d1711bdf74150c
-  data.tar.gz: 3fa7b2a4f0d31ae9d7f1234339ebca434e391c50
+  metadata.gz: 5ef93eb2e7a62a3b82fc6b2861f5206bcad851dd
+  data.tar.gz: 2c9cc2406ff56d8ea45a191150b686a890a2b7ff
 SHA512:
-  metadata.gz: c960ba5b529beee09ac5721bc591873ad3b4a046024924df0d8fc3efd8cb57bbc1ca07d6a1a522e2786c92a336e0763c898c954cbc58b7a0bd333f86e00c60b5
-  data.tar.gz: b26c8fbca31fcbc936833b7cfab2b124ecdecd7a58bdabc7866053374a40493a63b23ce001777eeb2e557a6916f7d123a3415a5c36966da855d644522c8b719b
+  metadata.gz: 4b6ba3bb814cf315c7ea136a26e71b8d0bc1d227e37e14f4230dc05e400a4be5e219cac97f0ad03a18bdfc514e8a166fb22fd25f5d3cafc55700f4afd2a043e5
+  data.tar.gz: 4115af63f74e1e41cff1c0e0986ae96ce7415d0814e26f952bd9e7053ae9d0df19b852cd84efb01876237d0496ed91900a01019e9c2fab3793f5bc59a5e54b1a

data/README.md

@@ -77,11 +77,11 @@ service.disconnect()
 client.disconnect()
 ```
 
-The service takes a single argument -- the a name. This name is the name of the
+The service takes a single argument -- the name. This name is the name of the
 AMQP queue used to send messages to the service. A queue is like an email
 address, phone number or an IP address -- it's just a unique identifier. In this
-case, its identifer you use to direct messages to the service. The run method
-then causes the servers to listen on the queue.
+case, its identifer you use to direct messages to the service. The
+<tt>Service::run()</tt> method then causes the server to listen on the queue.
 
 The client sends 10 messages to the service, each containing monotonically
 increasing integer values. It waits for the response (using a blocking timeout)
@@ -90,7 +90,8 @@ after each call and checks the results.
 The client is under no obligation to wait for a response. This is just how we've
 coded the service in this example -- to send something back. The interaction
 between the two forms an ad-hoc protocol. Hence the point of this project --
-quick and easy network protocols with minimal code (thanks to Rabbit and Bunny).
+quick and easy network protocols with minimal code (thanks to RabbitMQ and
+Bunny).
 
 ## Clients
 
@@ -163,11 +164,12 @@ client.disconnect()
 
 You can run both in the same script by setting the service code to non-blocking
 (passing <tt>:blocking => false</tt> to the <tt>Service::run()</tt>
-method). Services in either blocking or non-blocking mode, enabling you to run
-them either in the same script as clients (non-blocking), or in separate scripts
-where they idle and wait for incoming messages (blocking). By default, services
-run in blocking mode, as it is assumed that they will be be run in their own
-independent scripts/processes.
+method). Services can run in either blocking or non-blocking mode, enabling you
+to run them either in the same script as clients (non-blocking), or in separate
+scripts where they idle and wait for incoming messages (blocking). By default,
+services run in blocking mode, as it is assumed that they will be be run in
+their own independent scripts/processes. Here is the above example in a single
+script where the services runs in non-blocking mode:
 
 ```ruby
 #!/usr/bin/env ruby
@@ -248,7 +250,7 @@ client.disconnect()
 service.disconnect()
 ```
 
-The <tt>call()</tt> method will block waiting for the reponse up to
+The <tt>call()</tt> method will block waiting for the response up to
 <tt>client.timeout</tt> seconds (floating point value). The default is 1
 second. You can change this to whatever value you like. If a timeout occurs,
 <tt>call()</tt> will return <tt>nil</tt>.
@@ -278,14 +280,14 @@ no sense to keep it around should it arrive sometime in the future.
 Notice that the service uses the <tt>Service::reply()</tt> method rather than
 the <tt>send()</tt> method to return a response. This method takes the original
 request message, extracts the <tt>to</tt> address along with message ID and
-addresses a message back to the client. It also adds a header value of
-<tt>reply=true</tt>. This header lets the client know that the message coming in
-is specifically a reply. This is needed this because what if another peer sent
-the client a message which happened to have the same message ID? The client
-would confuse that message as the reply from the service and that would mess
-things up fast. Therefore the <tt>reply</tt> flag lets the client know that the
-message is a reply to a previous request and can then use the message ID to
-correlate it with the original request.
+addresses a message back to the client. It also sets the <tt>correlation_id</tt>
+to the message ID. This correlates the reply and lets the client know that the
+message coming in is specifically a reply to a given message. This is needed
+this because what if another peer sent the client a message which happened to
+have the same message ID? The client would confuse that message as the reply
+from the service and that would mess things up fast. Therefore the
+<tt>corellation_id</tt> value lets the client know that the message is a reply
+to a previous request and can then use the message ID to correlate the two.
 
 ## Services
 
@@ -329,11 +331,11 @@ service.disconnect()
 ```
 
 The only thing we did is remove the <tt>exclusive</tt> attribute which is by
-default in the <tt>HareDO::Service</tt> base class. By making the queue this
-services uses non-exclusive, mulitple service instances can now connect and
-process requests. RabbitMQ will automatically distribute messages equally across
-all the running services, dividing up the load. You can now scale your service
-to as many machines and processes as you like.
+default in the <tt>HareDO::Service</tt> base class. By making the queue
+non-exclusive, mulitple service instances can now connect to it and process
+requests. RabbitMQ will automatically distribute messages equally across all the
+running services, dividing up the load. You can now scale your service to as
+many machines and processes as you like.
 
 ## Peers
 
@@ -371,7 +373,7 @@ end # class Plugin
 ```
 
 Plugins are loaded in anonymous modules at runtime, each having its own private
-namespaces. The <tt>Peer</tt> class then looks inside the anonymous module and
+namespace. The <tt>Peer</tt> class then looks inside the anonymous module and
 extracts the <tt>Plugin</tt> class defined within, instantiates it, and adds it
 to the set of loaded modules.
 
@@ -393,7 +395,7 @@ service.listen(:blocking => false)
 
 client = HareDo::Peer.new()
 client.connect(:user=>$mq_username, :password=>$mq_password, :host=>$mq_host)
-response = @client.call('myservice', headers=>{:uuid=>'echo'}, :data => 'jujifruit')
+response = @client.call('myservice', headers=>{:uuid=>'echo'}, :data=>'jujifruit')
 
 client.disconnect()
 service.disconnect()
@@ -434,13 +436,14 @@ In this case, every module in the Ruby path that has the name <tt>echo.rb</tt>
 will be a candidate. The first file to match will be loaded as the module. You
 can see that in this case, namespace collisions are a very real danger. That's
 why the <tt>@module_path_prefix</tt> member exists -- there is a very low
-probability that there will be another module named located in the Ruby path
-which has a relative directory and name of <tt>haredo/plugins/echo.rb</tt>.
+probability that there will be another module with a given name located in the
+Ruby path which has a relative directory and name of
+<tt>haredo/plugins/echo.rb</tt>.
 
 ### Configuration
 
 You can pass configuration data into a plugin when you load it using the
-<tt>Peer::plugins.loadConfig()</tt> method. This takes a HASH whose keys are the
+<tt>Peer::plugins.loadConfig()</tt> method. This takes a Hash whose keys are the
 names of the plugins to load and the values are Hashes passed into each plugin
 as the configuration. The contents of the configuration are complete up to you
 as the plugin author.

data/src/lib/haredo/config.rb

@@ -44,11 +44,7 @@ module Config
 
     peer = HareDo::Peer.new()
     
-    begin
-      connected = peer.connect(params)
-    rescue
-      return nil
-    end
+    peer.connect(params)
 
     return peer
   end

data/src/lib/haredo/peer.rb

@@ -217,20 +217,16 @@ class Peer
       port = ssl['port'] || '5671'
     end
 
-    begin
-      if use_ssl == true
-        @cnx = Bunny.new( "amqps://#{user}:#{password}@#{host}:#{port}#{vhost}",
-                          :tls_cert => tls_cert,
-                          :tls_key => tls_key,
-                          :tls_ca_certificates => tls_ca_certs)
-      else
-        @cnx = Bunny.new("amqp://#{user}:#{password}@#{host}:#{port}#{vhost}")
-      end
-
-      @cnx.start()
-    rescue Bunny::TCPConnectionFailed => e
-      return false
+    if use_ssl == true
+      @cnx = Bunny.new( "amqps://#{user}:#{password}@#{host}:#{port}#{vhost}",
+                        :tls_cert => tls_cert,
+                        :tls_key => tls_key,
+                        :tls_ca_certificates => tls_ca_certs)
+    else
+      @cnx = Bunny.new("amqp://#{user}:#{password}@#{host}:#{port}#{vhost}")
     end
+    
+    @cnx.start()
 
     @channel = @cnx.create_channel()
 

data/src/lib/haredo/service/admin/daemon.rb

@@ -35,7 +35,6 @@ class Interface < Admin::Interface
   end
 
   def startCommand()
-    $stderr.puts 'Daemon start'
 
     # Check if already running      
     if daemonPid() != nil
@@ -43,6 +42,14 @@ class Interface < Admin::Interface
       return
     end
     
+    if File.exist?($haredo_daemon_name) == false
+      msg = "Error: #{$haredo_daemon_name} does not exist."
+      $stderr.puts msg
+      exit 1
+    end
+
+    $stderr.puts 'Daemon start'
+
     fork do
       Process.daemon()
 

data/src/lib/haredo/version.rb

@@ -4,8 +4,8 @@ module HareDo
 VERSION_MAJ  = '2'
 VERSION_MIN  = '0'
 VERSION_CL   = ''
-VERSION_PL   = '8'
-VERSION      = '2.0.8-1'
-RELEASE_DATE = 'Fri, 07 Nov 2014 13:42:10 -0600'
+VERSION_PL   = '9'
+VERSION      = '2.0.9-1'
+RELEASE_DATE = 'Wed, 11 Mar 2015 14:46:11 -0500'
 
 end # module HareDo

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: haredo
 version: !ruby/object:Gem::Version
-  version: 2.0.8
+  version: 2.0.9
 platform: ruby
 authors:
 - Mike Owens
 autorequire: 
 bindir: src/bin
 cert_chain: []
-date: 2014-11-07 00:00:00.000000000 Z
+date: 2015-03-11 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bunny
@@ -40,7 +40,6 @@ files:
 - src/lib/haredo/peer.rb
 - src/lib/haredo/plugin.rb
 - src/lib/haredo/plugins/echo.rb
-- src/lib/haredo/plugins/example.rb
 - src/lib/haredo/plugins/status.rb
 - src/lib/haredo/service/admin/daemon.rb
 - src/lib/haredo/service/config.rb
@@ -66,7 +65,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.4.2
+rubygems_version: 2.4.5
 signing_key: 
 specification_version: 4
 summary: A simple client/server framework using RabbitMQ

data/src/lib/haredo/plugins/example.rb

@@ -1,17 +0,0 @@
-require 'json'
-require 'haredo/plugin'
-
-class Plugin < HareDo::Plugin
-
-  UUID = 'example'
-
-  def initialize(service, config)
-    super UUID, service, config 
-  end
-
-  def process(msg)
-    # Send back configuration
-    @peer.reply(msg, :data=>JSON::pretty_generate(@config))
-  end
-
-end # class Plugin