Hi Glenn,

I was really happy to see Brian's support behind this - I was feeling a bit
protective on his behalf, as this was his baby, but with is support, I am
totally for what you are doing/have done. To be honest, most of my interest
in the gem to date has been to make it work for active messaging and fix
bugs, not to go to the lengths you are now; I applaud your efforts.

A few comments below:

I have no personal opposition to what you have done. I reacted a bit
conservatively only as Brian had not weighed in yet, and I wanted to make
sure he was cool with this.

I'll try to get my changes in using your git rather than svn - I am not
using git for any of my own projects yet, so it will be a good excuse to get
more familiar.

I like consistency - if all the tests are moving to specs, I am cool with
it.
I agree that mocking is essential in testing code like this.

The "_receive" private method is passed in a connection, and tries once to
get a response frame, then returns nil if there is none.
The "receive" public method tries to establish a connection by calling
"socket", then uses "_receive" to try once to get a message.
Where "receive" can block is when the connection needs to be
(re)established, and the connection attribute reliable == true.

If the connection is good, it will therefore try to call "_receive" once
only, and so do what you are looking for.
If the connection is nil, it will try once to connect if reliable=false,
otherwise it will retry until it gets a connection - and therefore blocks.
So reliable=false essentially makes "receive" always behave in the
non-blocking way that you describe.

Well, that is a slight gloss - "_receive" does block, but only in order to
make sure that the entirety of a frame is read of the connection at once -
again, you want it to synchronize around this, as you don't want competing
threads to each get a piece of a single frame.  So that blocking I assume
you are not worried about - more it is the blocking retry logic that seems
to be your (understandable) concern.

One of the changes I have been working on is cleaning up the way recieve and
_receive are used (mostly because I found a bug in the retry logic, but also
to make it better and clearer), so this is an area that I believe needs work
anyway.

I am generally not a huge fan of the existing retry logic, which we are
touching on a bit here.
You either have no retries if you have reliable=false, or it retries
infinitely (or until success) if reliable=true - I would rather have retry
counts with a configurable max retry count - what do you think?

As I

queue, poll blocks since its using the same receive method.  No?

First off - I don't use poll, and neither does the Client that comes with
stomp gem; it is an unneeded wrapper on receive as far as I am concerned.
It really ought to be deprecated, removed, or repurposed to do something
useful.  The only thing it does is return nil if there is not a connection
already, whereas receive will open a connection if there is none. Never had
a reason to use this.

So yeah, that comment is not exactly true, as described above:
If reliable=false, then that is how both poll and receive will behave -
returning nil if there is no message or it can't make a connection
If reliable=true, it keeps retrying until it connects, and then keeps
retrying until it returns a message.

Set reliable=false, and that is what calling receive will do, except it does
not automatically disconnect.
We can add another method perhaps that also does he disconnect, but there
should be some method such as receive that does not do this, as
disconnecting will get rid of all your existing subscriptions, and you
really don't always want to do that - activemessaging relies on the fact
that once you have connected and subscribed, it can simply use receive to
get messages off without having the overhead of reconnecting and
resubscribing.

In some cases, I agree, and in those cases, we can have a different method,
or finer grained options for retry logic.  ActiveMessaging is built using
the assumption of a single connection with subscriptions to receive messages
as they come in, and not closing and resubscribing all the time.

Thanks again for the detailed response.  Actually much of what you

Of course not - I've spent alot of time in this code, for better or worse. I
hope my long-windedness can be slightly helpful to the new guard.

-Andrew