this is very similar behaviour to the Java client, whose semantics are defined by the JMS specification.
The JMS specification basically dictates that the connection (and by extension it's sessions [channels] although they do not in JMS have their own state) are created in "stopped" mode. that is they can be used to publish, but do not automatically process incoming messages. JMS says that until you do connection.start(), you receive nothing. What we should probably be doing therefore (and I can't remember if we've fixed this in the Java client) is starting the channel in suspended mode, and not unsuspending until we get a connection start. As for .NET ... it depends if we wish to model the API after the Java client, or use a different style API (perhaps someone else could comment on the API the C++ client uses for example). So, in answer to your questions... if you want the same API as Java... 1) It should not be an error to create an (asynchronous) message listener, it should be an error to call a synchronous receive. 2) After channels have been created 3) In java the whole reason given in the JMS spec is to allow the creation and addition of listeners before the messages start arriving. It will throw an exception if you try to do a synchronous receive though Hope this helps a little, Rob
