I have been making a few cleanups and fixing a few bugs on a
(temporary?) fork of the codehaus.org copy of the Ruby Stomp gem.  I
would encourage anyone who has issues that need fixing to submit
patches for code and or documentation as a pull request on GitHub.

http://github.com/grempe/stomp/tree/master

The intention is to provide all changes back to the original project
and they can decide if they would like to accept them and officially
release the changes we are submitting as a new version of the official
gem on rubyforge.

GitHub automatically generates new gems from the master branch of the
repo and I'll put instructions for installing the gem from github in
the README which can be found at the link above.

Please accompany all code changes with matching Rspec specs, which
should be mocked/stubbed so they don't make calls directly to external
servers, or to collaborating classes.

TODO : One thing I would personally like to see is an easy way to make
a synchronous request to the STOMP server which is non-blocking.  The
poll method seems broken to me, and receive appears to connect and
block until messages arrive.  Someone want to take that one on or show
me the error of my ways?  :-)

Happy coding!

Or, is what you mean a way to get a _response_ to a request where listening
for the response is not blocking?
This to me sounds like a contradiction - if it's synchronous, it means you
are waiting for the response, which means it is blocking, or you are
building into your logic on the main execution thread to check back at
various points in the program flow to see if there is a response, which is a
hard/impossible thing to contain in a method call.  All the API could
provide for that is the equivalent of the private _receive method which
looks for a new message once then returns.

Stomp as a protocol is designed so that you subscribe to destinations, and
the broker will then push messages to you over your open connection, but
that means some thread has to be listening/polling on that open connection
with some frequency to receive the messages.  So there you go, that's what
poll and receive do.

Receive loops checking to see if there is new incoming IO on the tcp port,
and once it gets a stomp frame, returns.  The _receive message tries once,
and then returns, so all receive does is call this in a loop till something
comes back.  Is what you want what _receive does, where it looks for a
message once and then quits, so it is not blocking?

Poll is just a synchronizing wrapper to make sure you don't have more than
one thread simultaneously trying to read the next message from off the
connection (imagine how ugly that could get, if we get 2 threads competing
to get IO off the connection, and end up with a single message read in
pieces by different threads).

I guess I just don't understand how you expect this all to work where some
thread isn't taken up busy trying to listen for incoming IO.

All you need to do is instantiate the Client, and use that to
This is the same approach in active messaging, where threads are started to
listen for messages.
Did you have another approach in mind?

If you don't want it to block, but you do want to listen for and then handle
messages whenever they arrive, that means you either need another thread, or
have breaks in the processing of the main thread to comeback and look for
incoming messages and handle them.

Anyway, let me know if I have misunderstood, and I look forward to your
contributions to stomp and messaging,

- Andrew Kuklewicz

Happy coding!

Thanks for taking the time to provide a detailed response.  Much
appreciated.

I'll provide some comments below:

On May 10, 12:34 pm, "Andrew Kuklewicz" <kooks...@gmail.com> wrote:

Or even better :-)  You can fork my git repo, and push the work onto
github and we can merge our git repos easily.  Or I'll give you commit
access to my git repo directly.  Once all the changes are cool in this
working area we can bundle it all up in a patchset and commit it all
back to the SVN trunk for official release.

All this being said, if there is opposition to this approach, I am
fine with providing someone with patches agains the svn repo for any
changes that I have done and closing down the GitHub version if there
is confusion.  I think I made clear the intentions in the readme on
the site though.

a) It is a much better testing framework IMHO. :-)
b) It has a built in mocking and stubbing framework so it will be
possible to build tests that:
    - Exercise only the class being tested (e.g. the Client and mock/
stub any calls to the Connection class).
   - Use mocks/stubs to mock the connection and responses from the
external stomp server.  This removes the dependency on having a
message queue running in order to run the tests (and allows you to
mock the expected response that the stomp spec says should be
returned, and not what different implementations of the spec actually
return.
  - Rspec provides mechanisms to keep the testing code more DRY.
Notice I was able to remove two of the test unit files completely
since they three files contained all of the same exact tests with only
the setup of the connection being different.  This makes maintenance
really hard.  Check out my start on Rspec where you'll see I was able
to duplicate the functionality and can run different setups against
the same suite of test cases.  You can see that in
http://github.com/grempe/stomp/tree/master/spec/client_spec.rb where I
specify it should 'it_should_behave_like "standard Client"'.

Cheers.

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.

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

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.

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

Basically, my socket() has an @hosts array and @host_index, and does
something like this:

  @host_index = (@host_index+1)%...@hosts.size
  host = @hosts[@host_index]
  begin
    s = TCPSocket.open host[:host], host[:port]
    _transmit(s, "CONNECT", {:login => host[:login], :passcode =>
host[:passcode]})
    ...

And I then open a "reliable with failover" connection using a method I
added:

Stomp::Connection.open_failover( [{:host => "host1"}, {:host =>
"host2", :port => 61007}] )

Ideally, if support for Stomp "URLs" was added to the gem, you could
pass something in similar to JMS's failover spec:

Stomp::Connection.open("failover:stomp://user:password@host1;stomp://
user:password@host2:61007")

If there's a better list for this discussion please let me know, I'm
very interested in seeing a robust Stomp failover just like JMS but I
haven't seen a good discussion group for the stomp gem itself.