[rabbitmq-discuss] Strange reaction to publishing message with invalid expiration.
james.gardner at noaa.gov
Tue Mar 12 14:49:31 GMT 2013
I found a behavior which, to me at least, acts more like a bug than a
It seems that when you publish a message with an invalid expiration
string (eg. "blah"), it renders that channel inoperable for consume
operations afterwards. I would think it should just discard the message.
In the official Java client, something closes the channel, although I
don't get any exception until I try to use it for the ensuing consume
In the PHP AMQP client (this one:
http://www.php.net/manual/en/book.amqp.php), the channel stays open but
when you execute $queue->consume(...) and look in the management
interface you can see it has not registered as a consumer on the queue
Given the commonalities, I assume these are different client
interpretations of the same broker behavior. I am not using transactions
or publisher confirms or anything fancy. I am less familiar with the
Java client so perhaps I am missing some sort of error handling?
RabbitMQ version: RabbitMQ 3.0.3, Erlang R14B04 on RHEL 6.4
PHP AMQP version is 1.0.1 (admittedly a little outdated)
Java client is version: 3.0.3
I can provide code for either client if you would like but I imagine you
can replicate it easily just by establishing a connection, then a single
channel, then publishing the 'bad' msg to a topic exchange, then trying
to consume off a queue bound to that exchange with '#'.
When you change expiration to a valid string integer, everything works
as you would wish.
Of course one answer, as the doctor joke goes, is to not 'move your arm
like that'. Which is fine so long as there's a choice, but if I were
creating messages and taking the expiration from a source outside my
program (eg. database), this error might occur at some point if the data
were bad. I could/should(?) sanitize/verify first of course, the point
is more that I thought the typical broker reaction to illegal data was
to deal with it 'silently' (as it does with an illegal user_id, for
example) rather than effectively make the channel unusable.
Is there a different way I (or the client code) should be handling this
or is this an unexpected broker behavior?
NWS - Internet Dissemination System
More information about the rabbitmq-discuss