haredo 2.0.8 → 2.0.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/README.md +31 -28
- data/src/lib/haredo/config.rb +1 -5
- data/src/lib/haredo/peer.rb +9 -13
- data/src/lib/haredo/service/admin/daemon.rb +8 -1
- data/src/lib/haredo/version.rb +3 -3
- metadata +3 -4
- data/src/lib/haredo/plugins/example.rb +0 -17
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 5ef93eb2e7a62a3b82fc6b2861f5206bcad851dd
|
4
|
+
data.tar.gz: 2c9cc2406ff56d8ea45a191150b686a890a2b7ff
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 4b6ba3bb814cf315c7ea136a26e71b8d0bc1d227e37e14f4230dc05e400a4be5e219cac97f0ad03a18bdfc514e8a166fb22fd25f5d3cafc55700f4afd2a043e5
|
7
|
+
data.tar.gz: 4115af63f74e1e41cff1c0e0986ae96ce7415d0814e26f952bd9e7053ae9d0df19b852cd84efb01876237d0496ed91900a01019e9c2fab3793f5bc59a5e54b1a
|
data/README.md
CHANGED
@@ -77,11 +77,11 @@ service.disconnect()
|
|
77
77
|
client.disconnect()
|
78
78
|
```
|
79
79
|
|
80
|
-
The service takes a single argument -- the
|
80
|
+
The service takes a single argument -- the name. This name is the name of the
|
81
81
|
AMQP queue used to send messages to the service. A queue is like an email
|
82
82
|
address, phone number or an IP address -- it's just a unique identifier. In this
|
83
|
-
case, its identifer you use to direct messages to the service. The
|
84
|
-
then causes the
|
83
|
+
case, its identifer you use to direct messages to the service. The
|
84
|
+
<tt>Service::run()</tt> method then causes the server to listen on the queue.
|
85
85
|
|
86
86
|
The client sends 10 messages to the service, each containing monotonically
|
87
87
|
increasing integer values. It waits for the response (using a blocking timeout)
|
@@ -90,7 +90,8 @@ after each call and checks the results.
|
|
90
90
|
The client is under no obligation to wait for a response. This is just how we've
|
91
91
|
coded the service in this example -- to send something back. The interaction
|
92
92
|
between the two forms an ad-hoc protocol. Hence the point of this project --
|
93
|
-
quick and easy network protocols with minimal code (thanks to
|
93
|
+
quick and easy network protocols with minimal code (thanks to RabbitMQ and
|
94
|
+
Bunny).
|
94
95
|
|
95
96
|
## Clients
|
96
97
|
|
@@ -163,11 +164,12 @@ client.disconnect()
|
|
163
164
|
|
164
165
|
You can run both in the same script by setting the service code to non-blocking
|
165
166
|
(passing <tt>:blocking => false</tt> to the <tt>Service::run()</tt>
|
166
|
-
method). Services in either blocking or non-blocking mode, enabling you
|
167
|
-
them either in the same script as clients (non-blocking), or in separate
|
168
|
-
where they idle and wait for incoming messages (blocking). By default,
|
169
|
-
run in blocking mode, as it is assumed that they will be be run in
|
170
|
-
independent scripts/processes.
|
167
|
+
method). Services can run in either blocking or non-blocking mode, enabling you
|
168
|
+
to run them either in the same script as clients (non-blocking), or in separate
|
169
|
+
scripts where they idle and wait for incoming messages (blocking). By default,
|
170
|
+
services run in blocking mode, as it is assumed that they will be be run in
|
171
|
+
their own independent scripts/processes. Here is the above example in a single
|
172
|
+
script where the services runs in non-blocking mode:
|
171
173
|
|
172
174
|
```ruby
|
173
175
|
#!/usr/bin/env ruby
|
@@ -248,7 +250,7 @@ client.disconnect()
|
|
248
250
|
service.disconnect()
|
249
251
|
```
|
250
252
|
|
251
|
-
The <tt>call()</tt> method will block waiting for the
|
253
|
+
The <tt>call()</tt> method will block waiting for the response up to
|
252
254
|
<tt>client.timeout</tt> seconds (floating point value). The default is 1
|
253
255
|
second. You can change this to whatever value you like. If a timeout occurs,
|
254
256
|
<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.
|
|
278
280
|
Notice that the service uses the <tt>Service::reply()</tt> method rather than
|
279
281
|
the <tt>send()</tt> method to return a response. This method takes the original
|
280
282
|
request message, extracts the <tt>to</tt> address along with message ID and
|
281
|
-
addresses a message back to the client. It also
|
282
|
-
|
283
|
-
is specifically a reply. This is needed
|
284
|
-
|
285
|
-
|
286
|
-
|
287
|
-
|
288
|
-
|
283
|
+
addresses a message back to the client. It also sets the <tt>correlation_id</tt>
|
284
|
+
to the message ID. This correlates the reply and lets the client know that the
|
285
|
+
message coming in is specifically a reply to a given message. This is needed
|
286
|
+
this because what if another peer sent the client a message which happened to
|
287
|
+
have the same message ID? The client would confuse that message as the reply
|
288
|
+
from the service and that would mess things up fast. Therefore the
|
289
|
+
<tt>corellation_id</tt> value lets the client know that the message is a reply
|
290
|
+
to a previous request and can then use the message ID to correlate the two.
|
289
291
|
|
290
292
|
## Services
|
291
293
|
|
@@ -329,11 +331,11 @@ service.disconnect()
|
|
329
331
|
```
|
330
332
|
|
331
333
|
The only thing we did is remove the <tt>exclusive</tt> attribute which is by
|
332
|
-
default in the <tt>HareDO::Service</tt> base class. By making the queue
|
333
|
-
|
334
|
-
|
335
|
-
|
336
|
-
|
334
|
+
default in the <tt>HareDO::Service</tt> base class. By making the queue
|
335
|
+
non-exclusive, mulitple service instances can now connect to it and process
|
336
|
+
requests. RabbitMQ will automatically distribute messages equally across all the
|
337
|
+
running services, dividing up the load. You can now scale your service to as
|
338
|
+
many machines and processes as you like.
|
337
339
|
|
338
340
|
## Peers
|
339
341
|
|
@@ -371,7 +373,7 @@ end # class Plugin
|
|
371
373
|
```
|
372
374
|
|
373
375
|
Plugins are loaded in anonymous modules at runtime, each having its own private
|
374
|
-
|
376
|
+
namespace. The <tt>Peer</tt> class then looks inside the anonymous module and
|
375
377
|
extracts the <tt>Plugin</tt> class defined within, instantiates it, and adds it
|
376
378
|
to the set of loaded modules.
|
377
379
|
|
@@ -393,7 +395,7 @@ service.listen(:blocking => false)
|
|
393
395
|
|
394
396
|
client = HareDo::Peer.new()
|
395
397
|
client.connect(:user=>$mq_username, :password=>$mq_password, :host=>$mq_host)
|
396
|
-
response = @client.call('myservice', headers=>{:uuid=>'echo'}, :data
|
398
|
+
response = @client.call('myservice', headers=>{:uuid=>'echo'}, :data=>'jujifruit')
|
397
399
|
|
398
400
|
client.disconnect()
|
399
401
|
service.disconnect()
|
@@ -434,13 +436,14 @@ In this case, every module in the Ruby path that has the name <tt>echo.rb</tt>
|
|
434
436
|
will be a candidate. The first file to match will be loaded as the module. You
|
435
437
|
can see that in this case, namespace collisions are a very real danger. That's
|
436
438
|
why the <tt>@module_path_prefix</tt> member exists -- there is a very low
|
437
|
-
probability that there will be another module
|
438
|
-
which has a relative directory and name of
|
439
|
+
probability that there will be another module with a given name located in the
|
440
|
+
Ruby path which has a relative directory and name of
|
441
|
+
<tt>haredo/plugins/echo.rb</tt>.
|
439
442
|
|
440
443
|
### Configuration
|
441
444
|
|
442
445
|
You can pass configuration data into a plugin when you load it using the
|
443
|
-
<tt>Peer::plugins.loadConfig()</tt> method. This takes a
|
446
|
+
<tt>Peer::plugins.loadConfig()</tt> method. This takes a Hash whose keys are the
|
444
447
|
names of the plugins to load and the values are Hashes passed into each plugin
|
445
448
|
as the configuration. The contents of the configuration are complete up to you
|
446
449
|
as the plugin author.
|
data/src/lib/haredo/config.rb
CHANGED
data/src/lib/haredo/peer.rb
CHANGED
@@ -217,20 +217,16 @@ class Peer
|
|
217
217
|
port = ssl['port'] || '5671'
|
218
218
|
end
|
219
219
|
|
220
|
-
|
221
|
-
|
222
|
-
|
223
|
-
|
224
|
-
|
225
|
-
|
226
|
-
|
227
|
-
@cnx = Bunny.new("amqp://#{user}:#{password}@#{host}:#{port}#{vhost}")
|
228
|
-
end
|
229
|
-
|
230
|
-
@cnx.start()
|
231
|
-
rescue Bunny::TCPConnectionFailed => e
|
232
|
-
return false
|
220
|
+
if use_ssl == true
|
221
|
+
@cnx = Bunny.new( "amqps://#{user}:#{password}@#{host}:#{port}#{vhost}",
|
222
|
+
:tls_cert => tls_cert,
|
223
|
+
:tls_key => tls_key,
|
224
|
+
:tls_ca_certificates => tls_ca_certs)
|
225
|
+
else
|
226
|
+
@cnx = Bunny.new("amqp://#{user}:#{password}@#{host}:#{port}#{vhost}")
|
233
227
|
end
|
228
|
+
|
229
|
+
@cnx.start()
|
234
230
|
|
235
231
|
@channel = @cnx.create_channel()
|
236
232
|
|
@@ -35,7 +35,6 @@ class Interface < Admin::Interface
|
|
35
35
|
end
|
36
36
|
|
37
37
|
def startCommand()
|
38
|
-
$stderr.puts 'Daemon start'
|
39
38
|
|
40
39
|
# Check if already running
|
41
40
|
if daemonPid() != nil
|
@@ -43,6 +42,14 @@ class Interface < Admin::Interface
|
|
43
42
|
return
|
44
43
|
end
|
45
44
|
|
45
|
+
if File.exist?($haredo_daemon_name) == false
|
46
|
+
msg = "Error: #{$haredo_daemon_name} does not exist."
|
47
|
+
$stderr.puts msg
|
48
|
+
exit 1
|
49
|
+
end
|
50
|
+
|
51
|
+
$stderr.puts 'Daemon start'
|
52
|
+
|
46
53
|
fork do
|
47
54
|
Process.daemon()
|
48
55
|
|
data/src/lib/haredo/version.rb
CHANGED
@@ -4,8 +4,8 @@ module HareDo
|
|
4
4
|
VERSION_MAJ = '2'
|
5
5
|
VERSION_MIN = '0'
|
6
6
|
VERSION_CL = ''
|
7
|
-
VERSION_PL = '
|
8
|
-
VERSION = '2.0.
|
9
|
-
RELEASE_DATE = '
|
7
|
+
VERSION_PL = '9'
|
8
|
+
VERSION = '2.0.9-1'
|
9
|
+
RELEASE_DATE = 'Wed, 11 Mar 2015 14:46:11 -0500'
|
10
10
|
|
11
11
|
end # module HareDo
|
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: haredo
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 2.0.
|
4
|
+
version: 2.0.9
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Mike Owens
|
8
8
|
autorequire:
|
9
9
|
bindir: src/bin
|
10
10
|
cert_chain: []
|
11
|
-
date:
|
11
|
+
date: 2015-03-11 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: bunny
|
@@ -40,7 +40,6 @@ files:
|
|
40
40
|
- src/lib/haredo/peer.rb
|
41
41
|
- src/lib/haredo/plugin.rb
|
42
42
|
- src/lib/haredo/plugins/echo.rb
|
43
|
-
- src/lib/haredo/plugins/example.rb
|
44
43
|
- src/lib/haredo/plugins/status.rb
|
45
44
|
- src/lib/haredo/service/admin/daemon.rb
|
46
45
|
- src/lib/haredo/service/config.rb
|
@@ -66,7 +65,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
|
|
66
65
|
version: '0'
|
67
66
|
requirements: []
|
68
67
|
rubyforge_project:
|
69
|
-
rubygems_version: 2.4.
|
68
|
+
rubygems_version: 2.4.5
|
70
69
|
signing_key:
|
71
70
|
specification_version: 4
|
72
71
|
summary: A simple client/server framework using RabbitMQ
|
@@ -1,17 +0,0 @@
|
|
1
|
-
require 'json'
|
2
|
-
require 'haredo/plugin'
|
3
|
-
|
4
|
-
class Plugin < HareDo::Plugin
|
5
|
-
|
6
|
-
UUID = 'example'
|
7
|
-
|
8
|
-
def initialize(service, config)
|
9
|
-
super UUID, service, config
|
10
|
-
end
|
11
|
-
|
12
|
-
def process(msg)
|
13
|
-
# Send back configuration
|
14
|
-
@peer.reply(msg, :data=>JSON::pretty_generate(@config))
|
15
|
-
end
|
16
|
-
|
17
|
-
end # class Plugin
|