nebulous_stomp 2.0.1 → 2.0.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 210d0ff5d3c99590ab6356e5456e2fa67e9ab0ae
-  data.tar.gz: ac6782c4ef1969f7f0854de505a393927487cd00
+  metadata.gz: a4ac7c514b6d925e6186924b2dd93a175de94e02
+  data.tar.gz: 8aca7aa180be4c84fe6ccbe89b172980cd2a56a1
 SHA512:
-  metadata.gz: e12b2880dff2e61135575fcb2f694315621fcd8a69f29156e01eec0d1248b8f679241d1907bf75da452ec3bb6cf69152009e364ed9aeaa218b2735c929a7daf2
-  data.tar.gz: 2e5a0161b8c527dd8633562d1f359b781e105554a4c4d396c2dcba265f78750c0697051d0049cc9f26e6ef060b68cc97358d358e64a6caa1d0a64d3065922f92
+  metadata.gz: abb4de512e2aec3d8720505f9f06d7a00b2d5aa4caba2a1e9dab977f6c36cb6970f791289509cc6fbe96b945d6eeec84a65d7fe86b54d7402b97104dcd71c18d
+  data.tar.gz: 3e44c452fa7f94cd331cfc637b90b427c5171bd7fa9663b4ebe5118320e8d1ea8554628b57bcecfcc55cbc2f7f69aed9d13f49951c8e1ce82836db55cb7b26d5

data/.hgtags

@@ -16,3 +16,4 @@ cff04defabb0895ff2f032087b97ea9616bee6a9 1.14
 6ddf180c9a2fc1cef55f5d128faa4d5df28d1353 1.1.5
 6da65ce15fab9722deb05d8c0ed2d0c8e2cfe2ff 2.0.0
 9c4ec9af8f6b8a848082bf118be037696ff357c7 2.0.1
+63eb0028eeedf7cc3938fd8ecda1add9246fb905 2.02

data/lib/nebulous_stomp/nebrequest.rb

@@ -18,18 +18,6 @@ module NebulousStomp
     # The target name as set up by call to Nebulous::add_target
     attr_reader :target
     
-    # The 'verb' part of the message
-    attr_reader :verb      
-    
-    # The 'parameters' part of the message
-    attr_reader :params    
-
-    # The 'description' part of the message
-    attr_reader :desc
-    
-    # The 'replyID' header to use in this message 
-    attr_reader :replyID
-
     # Message timeout in seconds
     attr_reader :mTimeout
 
@@ -73,21 +61,23 @@ module NebulousStomp
       NebulousStomp.logger.debug(__FILE__) {"New NebRequest for verb #{verb}"}
 
       @target        = target.to_s
-      @verb          = verb.to_s
-      @params        = params.nil? ? nil : params.to_s
-      @desc          = desc.nil?   ? nil : desc.to_s
       @stomp_handler = stompHandler 
       @redis_handler = redisHandler 
       @requestQ      = nil
       @responseQ     = nil
       @message       = nil
-      @replyID       = nil
       @mTimeout      = 0
       @cTimeout      = 0
 
+      xverb   = verb.to_s
+      xparams = params.nil? ? nil : params.to_s
+      xdesc   = desc.nil?   ? nil : desc.to_s
+
       @redis_handler ||= RedisHandler.new( Param.get(:redisConnectHash) )
       @stomp_handler ||= StompHandler.new( Param.get(:stompConnectHash) )
 
+      neb_setup if nebulous_on?
+      @message = Message.from_parts(@responseQ, nil, xverb, xparams, xdesc)
       neb_connect if nebulous_on?
     end
 
@@ -112,7 +102,7 @@ module NebulousStomp
 
       # If we've lost the connection then reconnect but *keep replyID*
       @stomp_handler.stomp_connect unless @stomp_handler.connected?
-      @replyID = @stomp_handler.calc_reply_id if @replyID.nil? 
+      @message.reply_id = @stomp_handler.calc_reply_id if @message.reply_id.nil? 
 
       neb_qna(mTimeout)
 
@@ -201,14 +191,23 @@ module NebulousStomp
     end
 
 
+    #
+    # Some of our attributes are actually on Message
+    #
+
+    def verb;    @message ? @message.verb     : nil; end
+    def params;  @message ? @message.params   : nil; end
+    def desc;    @message ? @message.desc     : nil; end
+    def replyID; @message ? @message.reply_id : nil; end
+
+
     private
 
 
     ##
     # Connect to STOMP etc and do initial setup
-    # Called automatically by initialize, if Nebulous is 'on' in the config.
     #
-    def neb_connect
+    def neb_setup
       targetHash = Param.get_target(@target)
       raise NebulousError, "Unknown target #{target}" if targetHash.nil?
 
@@ -216,11 +215,16 @@ module NebulousStomp
       @mTimeout  = targetHash[:messageTimeout] || Param.get(:messageTimeout)
       @requestQ  = targetHash[:sendQueue]
       @responseQ = targetHash[:receiveQueue]
-      @message   = Message.from_parts(@responseQ, nil, verb, params, desc)
 
-      @stomp_handler.stomp_connect
-      @replyID = @stomp_handler.calc_reply_id
+      self
+    end
 
+
+    # Called automatically by initialize, if Nebulous is 'on' in the config.
+    #
+    def neb_connect
+      @stomp_handler.stomp_connect
+      @message.reply_id = @stomp_handler.calc_reply_id 
       self
     end
 
@@ -236,7 +240,12 @@ module NebulousStomp
 
       response = nil
       @stomp_handler.listen_with_timeout(@responseQ, mTimeout) do |msg|
-        response = msg
+        if replyID && msg.in_reply_to != replyID
+          false
+        else
+          response = msg
+          true
+        end
       end
 
       response

data/lib/nebulous_stomp/redis_handler.rb

@@ -17,11 +17,15 @@ module NebulousStomp
     ##
     # Initialise an instance of the handler by passing it the connection hash
     #
+    # If no hash is passed, we try and get it from Nebulous::Params
+    #
     # We use the optional testRedis parameter to mock connections to Redis, for
     # testing. It's probably of no use to anyone else.
     #
-    def initialize(connectHash, testRedis=nil)
-      @redis_hash = connectHash ? connectHash.dup : nil
+    def initialize(connectHash=nil, testRedis=nil)
+      @redis_hash   = connectHash ? connectHash.dup : nil
+      @redis_hash ||= Param.get(:redisConnectHash)
+
       @test_redis = testRedis 
       @redis      = nil
     end

data/lib/nebulous_stomp/stomp_handler.rb

@@ -110,10 +110,14 @@ module NebulousStomp
 
     ##
     # Initialise StompHandler by passing the parameter hash.
+    #
+    # If no hash is set we try and get it from NebulousStomp::Param.
     # ONLY set testClient when testing.
     #
-    def initialize(connectHash, testClient=nil)
-      @stomp_hash  = connectHash ? connectHash.dup : nil
+    def initialize(connectHash=nil, testClient=nil)
+      @stomp_hash   = connectHash ? connectHash.dup : nil
+      @stomp_hash ||= Param.get(:stompConnectHash)
+
       @test_client = testClient
       @client      = nil
     end
@@ -207,11 +211,13 @@ module NebulousStomp
     ##
     # As listen() but give up after yielding a single message, and only wait
     # for a set number of seconds before giving up anyway.
-    #--
-    # Ideally I'd like to DRY this and listen() up, but with this
-    # yield-within-a-thread stuff going on, I'm actually not sure how to do
-    # that safely.
-    #++
+    #
+    # The behaviour here is slightly different than listen(). If you return true from your block,
+    # the message will be consumed and the method will end.  Otherwise it will continue until it
+    # sees another message, or reaches the timeout.
+    #
+    # Put another way, since most things are truthy -- if you want to examine messages to find the
+    # right one, return false from the block to get another.
     #
     def listen_with_timeout(queue, timeout)
       return unless nebulous_on?
@@ -230,11 +236,13 @@ module NebulousStomp
         @client.subscribe( queue, {ack: "client-individual"} ) do |msg|
 
           begin
-            unless msg.body == "boo"
-              yield Message.from_stomp(msg) 
-              done = true
+            if msg.body == "boo"
+              @client.ack(msg)
+            else
+              done = yield Message.from_stomp(msg) 
+              @client.ack(msg) if done
             end
-            @client.ack(msg)
+
           rescue =>e
             NebulousStomp.logger.error(__FILE__) {"Error during polling: #{e}" }
           end

data/lib/nebulous_stomp/version.rb

@@ -1,5 +1,5 @@
 module NebulousStomp
 
   # Nebulous version number
-  VERSION = "2.0.1"
+  VERSION = "2.0.2"
 end

data/md/nebulous_protocol.md

@@ -1,59 +1,51 @@
 Nebulous: The Protocol
 ======================
 
-(It was going to be "The Nebulous Protocol", but that sounds like something with
-Matt Damon in it.)
+(It was going to be "The Nebulous Protocol", but that sounds like something with Matt Damon in it.)
 
 
 Introduction
 ------------
-Project Nebulous is a STOMP client written in ABL, and also the protocol that
-allows our different systems, ABL or not, to pass messages. This document,
-obviously, concentrates on the protocol.
+Project Nebulous is a STOMP client written in ABL, and also the protocol that allows our different
+systems, ABL or not, to pass messages. This document, obviously, concentrates on the protocol.
 
-The basic idea is this: one system passes a message, a _request_; and then
-waits for an answer to that message, a _response_, from another system. STOMP 
-doesn't explicitly support that; the protocol does it.
+The basic idea is this: one system passes a message, a _request_; and then waits for an answer to
+that message, a _response_, from another system. STOMP doesn't explicitly support that; the
+protocol does it.
 
-(Note that a request and a response are just notional terms; you might in
-theory have a request which provokes a response which provokes another response
-in return, in which case the second message is both a response and a request, 
-and the terms get rather less useful.)
+(Note that a request and a response are just notional terms; you might in theory have a request
+which provokes a response which provokes another response in return, in which case the second
+message is both a response and a request, and the terms get rather less useful.)
 
 
 The Protocol
 ------------
-Let's start with the actual protocol, the rules. They won't make sense without
-reading the rest of the document, but:
+Let's start with the actual protocol, the rules. They won't make sense without reading the rest of the document, but:
 
-1. Every valid request (that is, every message with an identifiable verb other
-   than "success" or "error") will always generate a response. If the handling
-   routine cannot generate a valid response, or if there is no routine to handle
-   the verb in question, then the response should be the error verb. If no
-   response is required, you should still receive the success verb.
+1. Every valid request (that is, every message with an identifiable verb other than "success" or
+   "error") will always generate a response. If the handling routine cannot generate a valid
+   response, or if there is no routine to handle the verb in question, then the response should be
+   the error verb. If no response is required, you should still receive the success verb.
 
-2. You should expect that requests that do not have a verb will not be responded
-   to or even understood. (However, there is no general requirement for message
-   bodies to follow the verb / parameters / description format. If you have a
-   program that sends a request and waits for a response, the format of that
-   response is outside the remit of The Protocol.)
+2. You should expect that requests that do not have a verb will not be responded to or even
+   understood. (However, there is no general requirement for message bodies to follow the verb /
+   parameters / description format. If you have a program that sends a request and waits for a
+   response, the format of that response is outside the remit of The Protocol.)
 
-3. If a request has the _neb-reply-to_ header, the response should use that as
-   a destination; otherwise it should be sent to the same destination that the
-   request was sent to.
+3. If a request has the _neb-reply-to_ header, the response should use that as a destination;
+   otherwise it should be sent to the same destination that the request was sent to.
 
-4. If the request has a _neb-reply-id_ header, then the response should set the
-   _neb-in-reply-to_ header to that.
+4. If the request has a _neb-reply-id_ header, then the response should set the _neb-in-reply-to_
+   header to that.
 
-5. The request may specify the content type of a response (JSON or text) by
-   it's own content type. That is, if a response can be in either form, it
-   should take the form of the request as an indication as which to use.
+5. The request may specify the content type of a response (JSON or text) by it's own content type.
+   That is, if a response can be in either form, it should take the form of the request as an
+   indication as which to use.
 
-6. A given queue that is the target of requests within The Protocol will be for
-   only one system or common group of systems. They may consume (ACK) messages
-   sent to it even if they do not have the facility to process them.  If
-   multiple systems share a queue, they should understand that messages will be
-   consumed from it at random.
+6. A given queue that is the target of requests within The Protocol will be for only one system or
+   common group of systems. They may consume (ACK) messages sent to it even if they do not have the
+   facility to process them.  If multiple systems share a queue, they should understand that
+   messages will be consumed from it at random.
 
 
 Components
@@ -64,130 +56,112 @@ By way of an explanation of the above section.
 
 STOMP allows you to define custom headers. We have three. 
 
-* _neb-reply-to_ is may be set on a request to the destination that any
-  response should be posted to. 
+* _neb-reply-to_ is may be set on a request to the destination that any response should be posted
+  to. (See rule 3.)
 
-* _neb-reply-id_ may be set on a request to an arbitrary string to help
-  you identify the response.
+* _neb-reply-id_ may be set on a request to an arbitrary string to help you identify the response.
 
-* _neb-in-reply-to_ is set on a response and contains the nebulous-reply-id
-  of the request.
+* _neb-in-reply-to_ is set on a response and contains the neb-reply-id of the request. (see rule 4.)
 
 ### Message Body ###
 
-The Protocol specifies a format for the message body. It consists of three
-fields:
+The Protocol specifies a format for the message body. It consists of three fields:
 
-* _verb_ is the keyword that tells the receiving system how to process the
-  message.
+* _verb_ is the keyword that tells the receiving system how to process the message.
 
-* _parameters_ is an arbitrary field that is context-dependant on verb. The
-  routine that handles the verb is expected to be able to parse it. It is
-  optional.
+* _parameters_ is an arbitrary field that is context-dependant on verb. The routine that handles
+  the verb is expected to be able to parse it. It is optional.
 
 * _description_ is a text field and can contain anything. It is optional.
 
-Nebulous supports message bodies in either JSON (in which case parameters is an
-array) or plain text (in which case it expects to find the fields formatted in
-the same way as STOMP headers: seperated by line breaks, where each line
-consists of the field name, a colon, and the value).
+Nebulous supports message bodies in either JSON (in which case parameters is probably an array) or
+plain text (in which case it expects to find the fields formatted in the same way as STOMP headers:
+seperated by line breaks, where each line consists of the field name, a colon, and the value).
 
 There are a couple of special verbs:
 
-* _success_ as a verb in a response is used when no information needs to be
-  returned except that the request operation went ahead without problem.
+* _success_ as a verb in a response is used when no information needs to be returned except that
+  the request operation went ahead without problem.
 
-* _error_ as a verb is used when the requested operation failed. The
-  expectation is that you will put an error message in the description field;
-  you can use parameters as you see fit, of course.
+* _error_ as a verb is used when the requested operation failed. The expectation is that you will
+  put an error message in the description field; you can use parameters as you see fit, of course.
 
 
 Notes on usage
 --------------
-There are two use cases here. The first (let's call it _Q & A_) is when a
-process needs information and sends a request, then waits for a response. The
-second (let's call it _Responder_) is at the other end of that process; it
-camps onto one or more queues waiting for requests, and arranges for responses
-to be sent.
+
+There are two use cases here. The first (let's call it _Q & A_) is when a process needs information
+and sends a request, then waits for a response. The second (let's call it _Responder_) is at the
+other end of that process; it camps onto one or more queues waiting for requests, and arranges for
+responses to be sent.
 
 ### Responder ###
 
-Let's talk about the Responder use case first, since it's simpler; we've
-basically been talking about it for the whole of this document. You'll need to
-designate a queue for incoming requests on any given system. You might want
-more than one; in ABL, where traffic jams are likely because I can't just
-spawn up a thread to handle each incoming message, my current thinking is to
-have two incoming queues, one for reqests that take a few seconds, and another
-for requests that take longer. 
-
-Remember that rule 6 says that any messages that go to a queue like this will
-be consumed without concern for whether the message will make sense to the
-system in question; this is basically there so that the ABL code can split up
-the process of grabbing new messages from the process of working out what they
-are and how to answer them. 
-
-But the simplicity is appealing, regardless: post to this queue and the
-Responder that looks after this system will process it. Rule 1 guarantees
-you an answer so long as the system is up, so if you don't get one then either
-the target system is down or it's too busy to respond.
-
-The expectation is that the Responder system should use the verb of the message
-to control how it is dealt with. The parameters field is verb-specific; the
-combination of verb, expected parameters, and the nature of the returned
-message form a sort of contract, ie "verb x always expects parameters like
-this, and always behaves like that in response". This is partly implied by Rule
-2, I think.
+Let's talk about the Responder use case first, since it's simpler; we've basically been talking
+about it for the whole of this document. You'll need to designate a queue for incoming requests on
+any given system. You might want more than one; in ABL, where traffic jams are likely because I
+can't just spawn up a thread to handle each incoming message, my current thinking is to have two
+incoming queues, one for reqests that take a few seconds, and another for requests that take
+longer. 
+
+Remember that rule 6 says that any messages that go to a queue like this will be consumed without
+concern for whether the message will make sense to the system in question; this is basically there
+so that the ABL code can split up the process of grabbing new messages from the process of working
+out what they are and how to answer them. 
+
+But the simplicity is appealing, regardless: post to this queue and the Responder that looks after
+this system will process it. Rule 1 guarantees you an answer so long as the system is up, so if you
+don't get one then either the target system is down or it's too busy to respond.
+
+The expectation is that the Responder system should use the verb of the message to control how it
+is dealt with. The parameters field is verb-specific; the combination of verb, expected parameters,
+and the nature of the returned message form a sort of contract, ie "verb x always expects
+parameters like this, and always behaves like that in response". This is partly implied by Rule 2,
+I think.
 
 ### Q & A ###
 
-The Q & A use case is more interesting since it's what the whole thing is for,
-but some of it really falls outside of The Protocol.
-
-In theory, Rule 3 says you can fail to use _neb-reply-to_ and pick up your
-response from the same queue you posted the message to. But rule 6 says that if
-you do that you don't have any guarantee at all of getting your message; the
-Responder will take it. So for practical purposes you almost always *have* to
-set a reply-to queue in your request. 
-
-Likewise, Rule 4 says that _neb-reply-id_ is optional. But in practice you
-should almost certainly set it. Yes, you can specify a brand new queue that is
-unique to your request -- or probably unique, anyway -- but it turns out that
-some message servers, our RabbitMQ included, don't let you subscribe to a queue
-that doesn't exist. It's easy enough to create a queue: you just send a message
-to it. But now there are two messages in that queue (or more if turns out that
-you've got some queue namespace collision after all) and you have to pick your
-response from it, and the easiest way is to set a reply id.
-
-So let's assume a median worst case: you're posting a request to a Responder
-queue with a reply-id set to something hopefully unique, and reply-to set to a
-common queue that many processes use to pick up replies. There are two
-challenges here: first, working out which message is yours; second, avoiding
-consuming those messages that are not.
-
-For a unique reply-id you could do worse than starting with the session ID that
-STOMP returns when you send a CONNECT frame; clearly the message server thinks
-that is unique, and it should know. In the Ruby Stomp gem, you can get it with
-`client.connection_frame().headers["session"]` where client is your
-`Stomp::Client` instance; in my ABL jhstomp.p library call `get_session_id()`.
-
-Now that you have a good reply ID you can tell which is yours by Rule 4; just
-test the _neb-in-reply-to_ header of each message. 
-
-The second problem, of avoiding consuming messages that don't match your
-reply-id, is handled by careful use of STOMP. If when subscribing you set the
-header `ack:client-individual`, then you must manually acknowledge each message
-you want to consume with an ACK frame.
-
-Finally, you get to handle the response. Rule 1 says that it will either be an
-error verb, a success verb ... or something else specific to the verb. The
-nature of messages in responses is really outside of The Protocol; you are free
-to use the verb / parameters / description format if you wish. Again, I'm
-assuming that a given verb will always require the same parameters and return
-the same message. I think that to do otherwise would be very confusing. But The
-Protocol can't enforce that. 
-
-Note also that while The Protocol says that a request should always result in a
-response, there is nothing to say that the sender of the request should care --
-say, in the example of a request that results in a report being emailed, which
-takes 20 minutes. 
+The Q & A use case is more interesting since it's what the whole thing is for, but some of it
+really falls outside of The Protocol.
+
+In theory, Rule 3 says you can fail to use _neb-reply-to_ and pick up your response from the same
+queue you posted the message to. But rule 6 says that if you do that you don't have any guarantee
+at all of getting your message; the Responder will take it. So for practical purposes you almost
+always *have* to set a reply-to queue in your request. 
+
+Likewise, Rule 4 says that _neb-reply-id_ is optional. But in practice you should almost certainly
+set it. Yes, you can specify a brand new queue that is unique to your request -- or probably
+unique, anyway -- but it turns out that some message servers, our RabbitMQ included, don't let you
+subscribe to a queue that doesn't exist. It's easy enough to create a queue: you just send a
+message to it. But now there are two messages in that queue (or more if turns out that you've got
+some queue namespace collision after all) and you have to pick your response from it, and the
+easiest way is to set a reply id.
+
+So let's assume a median worst case: you're posting a request to a Responder queue with a reply-id
+set to something hopefully unique, and reply-to set to a common queue that many processes use to
+pick up replies. There are two challenges here: first, working out which message is yours; second,
+avoiding consuming those messages that are not.
+
+For a unique reply-id you could do worse than starting with the session ID that STOMP returns when
+you send a CONNECT frame; clearly the message server thinks that is unique, and it should know. In
+the Ruby Stomp gem, you can get it with `client.connection_frame().headers["session"]` where client
+is your `Stomp::Client` instance; in my ABL jhstomp.p library call `get_session_id()`.
+
+Now that you have a good reply ID you can tell which is yours by Rule 4; just test the
+_neb-in-reply-to_ header of each message. 
+
+The second problem, of avoiding consuming messages that don't match your reply-id, is handled by
+careful use of STOMP. If when subscribing you set the header `ack:client-individual`, then you must
+manually acknowledge each message you want to consume with an ACK frame.
+
+Finally, you get to handle the response. Rule 1 says that it will either be an error verb, a
+success verb ... or something else specific to the verb. The nature of messages in responses is
+really outside of The Protocol; you are free to use the verb / parameters / description format if
+you wish. Again, I'm assuming that a given verb will always require the same parameters and return
+the same message. I think that to do otherwise would be very confusing. But The Protocol can't
+enforce that. 
+
+Note also that while The Protocol says that a request should always result in a response, there is
+nothing to say that the sender of the request should care -- say, in the example of a request that
+results in a report being emailed, which takes 20 minutes. 
 

data/spec/nebrequest_null_spec.rb

@@ -14,9 +14,9 @@ describe NebRequestNull do
 
   def disable(thing)
     NebulousStomp.init( :stompConnectHash => thing == :stomp ? {} : stomp_hash,
-                   :redisConnectHash => thing == :redis ? {} : redis_hash,
-                   :messageTimeout   => 5,
-                   :cacheTimeout     => 20 )
+                        :redisConnectHash => thing == :redis ? {} : redis_hash,
+                        :messageTimeout   => 5,
+                        :cacheTimeout     => 20 )
 
     NebulousStomp.add_target( :accord, 
                          :sendQueue      => "/queue/laplace.dev",
@@ -36,6 +36,7 @@ describe NebRequestNull do
 
   let(:redis_hash) { {host: '127.0.0.1', port: 6379, db: 0} }
 
+
   before do
     disable(:nothing)
   end
@@ -95,7 +96,7 @@ describe NebRequestNull do
 
     it "returns something from STOMP" do
       req = new_request('accord', 'foo')
-      req.insert_fake_stomp( Message.from_parts('', '', 'foo', 'bar', 'baz') )
+      req.insert_fake_stomp( Message.from_parts(nil, req.replyID, 'foo', 'bar', 'baz') )
       response = req.send_no_cache
 
       expect( response ).to be_a NebulousStomp::Message
@@ -124,7 +125,7 @@ describe NebRequestNull do
 
     it "returns a Message object from STOMP the first time" do
       req = new_request('accord', 'foo')
-      req.insert_fake_stomp( Message.from_parts('', '', 'foo', 'bar', 'baz') )
+      req.insert_fake_stomp( Message.from_parts(nil, req.replyID, 'foo', 'bar', 'baz') )
 
       response = req.send
       expect( response ).to be_a NebulousStomp::Message
@@ -133,7 +134,7 @@ describe NebRequestNull do
 
     it "returns the answer from the cache if there is one" do
       req = new_request('accord', 'foo')
-      req.insert_fake_stomp( Message.from_parts('', '', 'foo', 'bar', 'baz') )
+      req.insert_fake_stomp( Message.from_parts(nil, req.replyID, 'foo', 'bar', 'baz') )
       req.insert_fake_redis('xxx', {'verb' => 'frog'}.to_json)
       response = req.send
 
@@ -143,14 +144,14 @@ describe NebRequestNull do
 
     it "allows you to specify a message timeout" do
       req = new_request('accord', 'foo')
-      req.insert_fake_stomp( Message.from_parts('', '', 'foo', 'bar', 'baz') )
+      req.insert_fake_stomp( Message.from_parts(nil, req.replyID, 'foo', 'bar', 'baz') )
 
       expect{ req.send(3) }.not_to raise_exception
     end
 
     it "allows you to specify a message timeout & cache timeout" do
       req = new_request('accord', 'foo')
-      req.insert_fake_stomp( Message.from_parts('', '', 'foo', 'bar', 'baz') )
+      req.insert_fake_stomp( Message.from_parts(nil, req.replyID, 'foo', 'bar', 'baz') )
 
       expect{ req.send(3, 120) }.not_to raise_exception
     end
@@ -163,7 +164,7 @@ describe NebRequestNull do
     it 'still works if Redis is turned off in the config' do
       disable(:redis)
       r = new_request('accord', 'tom')
-      r.insert_fake_stomp( Message.from_parts('', '', 'foo', 'bar', 'baz') )
+      r.insert_fake_stomp( Message.from_parts(nil, r.replyID, 'foo', 'bar', 'baz') )
 
       response = r.send
       expect( response ).to be_a NebulousStomp::Message

data/spec/nebrequest_spec.rb

@@ -104,8 +104,8 @@ describe NebRequest do
   describe "#send_no_cache" do
 
     it "returns something from STOMP" do
-      stomp_h.insert_fake( Message.from_parts('', '', 'foo', 'bar', 'baz') )
       request = new_request('accord', 'foo')
+      stomp_h.insert_fake( Message.from_parts(nil, request.replyID, 'foo', 'bar', 'baz') )
       response = request.send_no_cache
 
       expect( response ).to be_a NebulousStomp::Message
@@ -133,8 +133,8 @@ describe NebRequest do
   describe "#send" do
 
     it "returns a Message object from STOMP the first time" do
-      stomp_h.insert_fake( Message.from_parts('', '', 'foo', 'bar', 'baz') )
       request = new_request('accord', 'foo')
+      stomp_h.insert_fake( Message.from_parts(nil, request.replyID, 'foo', 'bar', 'baz') )
 
       response = request.send
       expect( response ).to be_a NebulousStomp::Message
@@ -142,7 +142,7 @@ describe NebRequest do
     end
 
     it "returns the answer from the cache the second time" do
-      stomp_h.insert_fake( Message.from_parts('', '', 'foo', 'bar', 'baz') )
+      stomp_h.insert_fake( Message.from_parts(nil, nil, 'foo', 'bar', 'baz') )
       redis_h.insert_fake('xxx', {'verb' => 'frog'}.to_json)
 
       # First time
@@ -158,15 +158,15 @@ describe NebRequest do
     end
 
     it "allows you to specify a message timeout" do
-      stomp_h.insert_fake( Message.from_parts('', '', 'foo', 'bar', 'baz') )
       request = new_request('accord', 'foo')
+      stomp_h.insert_fake( Message.from_parts(nil, request.replyID, 'foo', 'bar', 'baz') )
 
       expect{ request.send(3) }.not_to raise_exception
     end
 
     it "allows you to specify a message timeout & cache timeout" do
-      stomp_h.insert_fake( Message.from_parts('', '', 'foo', 'bar', 'baz') )
       request = new_request('accord', 'foo')
+      stomp_h.insert_fake( Message.from_parts(nil, request.replyID, 'foo', 'bar', 'baz') )
 
       expect{ request.send(3, 120) }.not_to raise_exception
     end
@@ -178,8 +178,8 @@ describe NebRequest do
 
     it 'still works if Redis is turned off in the config' do
       rh = RedisHandlerNull.new({})
-      stomp_h.insert_fake( Message.from_parts('', '', 'foo', 'bar', 'baz') )
       r = NebRequest.new('accord', 'tom', nil, nil, stomp_h, rh)
+      stomp_h.insert_fake( Message.from_parts(nil, r.replyID, 'foo', 'bar', 'baz') )
 
       response = r.send
       expect( response ).to be_a NebulousStomp::Message

data/spec/stomp_handler_spec.rb

@@ -158,7 +158,6 @@ describe StompHandler do
 
     it "takes an initialization hash" do
       expect{ StompHandler.new(foo: 'bar') }.not_to raise_exception
-      expect{ StompHandler.new }.to raise_exception ArgumentError
     end
 
   end

data/spec/through_test_spec.rb

@@ -6,8 +6,9 @@ require 'nebulous_stomp'
 # It's really only here to double check that the Stomp gem hasn't moved the 
 # goalposts (again).
 #
-# In order for it to work, the JH RabbitMQ server has to be where we left it. 
-# So this test won't work for you out of the box, unless you are me.
+# In order for it to work, the JH RabbitMQ server has to be where we left it. And you need a
+# responder listening to /queue/nebulout.test for the 'ping' verb. So this test won't work for you
+# out of the box, unless you are me.
 #
 describe 'through test' do
 

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: nebulous_stomp
 version: !ruby/object:Gem::Version
-  version: 2.0.1
+  version: 2.0.2
 platform: ruby
 authors:
 - Andy Jones
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2016-06-21 00:00:00.000000000 Z
+date: 2016-08-23 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: bundler