[rabbitmq-discuss] Strange reaction to publishing message with invalid expiration.

[James Gardner]

Hi,
I found a behavior which, to me at least, acts more like a bug than a 
feature...
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 
operation.
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 
of interest.
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?
Thanks,

James Gardner
NWS - Internet Dissemination System