Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Connection IO not entirely managed by IO Processor #13
The following code illustrates a problem with how the client, io processor and event dispatching interact:
client = OnStomp::Client.open "stomp://localhost" client.on_connection_closed do client.connect end
This code introduces a race condition in both the 1.0 branch and what will be the 1.1 branch. In the 1.0 branch, the threaded processor works with the
In what will be the 1.1 branch, the issue is slightly different but just as serious: the system dead-locks as
The root of the problem is that establishing the connection is being handled in whatever thread invoked
It's also important to note that there will always be some interaction between the processor thread and the event dispatch thread, if we want to allow
A proper solution to this problem will also provide a more robust solution to issue #12
on a side note, when RST is received in the middle of communication during transaction from the broker, the following happens:
/usr/lib64/ruby/gems/1.8/gems/onstomp-1.0.5/lib/onstomp/connections/base.rb:314:in `read_nonblock': Connection reset by peer (Errno::ECONNRESET) from /usr/lib64/ruby/gems/1.8/gems/onstomp-1.0.5/lib/onstomp/components/threaded_processor.rb:57:in `join' from /usr/lib64/ruby/gems/1.8/gems/onstomp-1.0.5/lib/onstomp/components/threaded_processor.rb:57:in `join' from /usr/lib64/ruby/gems/1.8/gems/onstomp-1.0.5/lib/onstomp/client.rb:104:in `disconnect' from /usr/lib64/ruby/gems/1.8/gems/onstomp-1.0.5/lib/onstomp/client.rb:103:in `tap' from /usr/lib64/ruby/gems/1.8/gems/onstomp-1.0.5/lib/onstomp/client.rb:103:in `disconnect' from ./lib/sslchecker_client.rb:211:in `main' from ./lib/sslchecker_client.rb:224
This is wrong. First of all, you should handle exceptions. Secondly, you should call a callback for that transaction. on_abort would be a good candidate.
btw, i'm no expert, but the code itself is hard to follow.
I agree with you on both points. The reason there is only limited exception handling at the moment is that I've been trying to come up with a good way to handle them. Given that the exceptions are being raised within a separate thread, the user won't have the opportunity to
The RST packet should trigger
I also agree about the code being hard to follow. I've been considering factoring out some of it into separate gems (or removing some of the code in favor of existing gems that do the same thing.) This is particular true of the
Stomper and OnStomp were initially developed to address I problem I was having with the existing Stomp gem across a semi-unreliable network. Issues with read and write buffering in my environment caused Stomp to hang, which in turn choked the application I needed it for. So I wrote Stomper (and then OnStomp) to be fairly close to a drop-in replacement, but using Ruby's non-blocking IO methods. Switching over to eventmachine would have required re-writing a fair amount of the application itself to run within the event loop.