Hi Robert, > 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
That sounds like a good thing, i.e. it now makes more sense. So I guess the problem is that the current .NET client does *not* fault if the connection hasn't been started and you issue a sync receive (sync receives aren't quite fully implemented in the trunk yet, though I'm working on fixing it while I sort other stuff and I got a simple working implementation). One other question: Does the Java API allow you to attach multiple message listeners to a single consumer? Because the current .NET API only seems to be properly suited to attaching a single one... Tomas Restrepo [EMAIL PROTECTED] http://www.winterdom.com/weblog/
