So, according to the 0-9-1 definition ( https://www.amqp.org/specification/0-9-1/amqp-org-download), 404 is supposed to be a channel error - so RabbitMQ is likely more correct than the Java Broker. IIRC there were a whole boatload of issues with clients (particularly the old JMS client) trying to handle channel level exceptions, so the decision was made to just treat everything as a connection level exception. Others may have a more accurate/detailed memory.
-- Rob On Mon, 12 Jul 2021 at 14:31, Fraser Adams <fraser.ad...@blueyonder.co.uk.invalid> wrote: > For context I'm working on a project that is primarily using the > RabbitMQ broker and using the Pika Python client library. As the Qpid > Java broker supports AMQP 0.9.1 too I figured I'd try to connect to that > too to see if I could compare relative performance. > > I ran into a couple of issues, the first is that by default the Java > broker doesn't support PLAIN authentication on insecure transports so I > needed to mod the config.json to add > > "secureOnlyMechanisms" : [ ], > > to "authenticationproviders" > > I thought/hoped that'd be enough, but unfortunately things kept failing > with a 504 error complaining about channel :2 not existing > > > As it happens, what I'm actually doing during the startup of my > application is to check if an exchange with the name of the specified > destination exists. > > The way I do that is to do an exchange_declare with passive=True. Now I > know that when an exception/error occurs (e.g. a 404 NOT_FOUND) if the > exchange doesn't exist then the channel is closed by the broker. To > cater for this I create a temporary channel (in this case it would be > channel :2) and call the exchange_declare passive=True using that > channel and I get a pika.exceptions.ChannelClosedByBroker, which is what > I'd expect. > > So that's how it is with RabbitMQ broker, but with Qpid Java subsequent > things were failing and I narrowed it down to the connection having been > closed in addition to the channel. > > I've tried creating an additional temporary *connection* in addition to > the temporary channel that I was previously creating in order to run the > passive=True exchange_declare and doing that seems to "work" in terms of > the rest of the application now seems to carry on correctly. > > > So really I'm curious, is the Qpid Java broker closing the connection in > addition to closing the channel the expected behaviour in this scenario? > It is certainly different compared with what RabbitMQ does, but I have > no idea what the "correct" behaviour is in this circumstance. > > MTIA > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
