meadvillerb/onstomp — Issue #13: Connection IO not entirely managed by IO Processor
Author: iande
Created: 2011-10-14 12:19:08+00:00
State: open

The following code illustrates a problem with how the client, io processor and event dispatching interact:

```ruby
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 `connection` attribute of a client and as that attribute isn't synchronized, it may be possible to end up with multiple IO processor threads operating on the same connection object. This problem was pointed out in issue #12

In what will be the 1.1 branch, the issue is slightly different but just as serious: the system dead-locks as `client.connect` will not complete until certain event handlers are processed, but the dispatcher won't trigger those events until it has completed the triggering of `on_connection_closed`.

The root of the problem is that establishing the connection is being handled in whatever thread invoked `client.connect`, and the method blocks until the connection hand-shake has completed. The IO processor should handle creating and establishing the connection in addition to managing all the reads and writes.

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 `before_*` events to modify outgoing frames. Our only choice is to delay enqueueing the frame to write until all of the related events have been triggered.

A proper solution to this problem will also provide a more robust solution to issue #12