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

[Simon MacMullen]

Well, the channel is getting closed with an error message (same as it 
would be for an illegal user_id in fact). That's AMQP's approach to 
error handling.

You should be able to see an IOException getting thrown in the Java 
client, with a more descriptive cause property, or you can register a 
ShutdownListener. I have no idea how the PHP client signals errors I'm 
afraid.

Cheers, Simon

On 12/03/13 14:49, James Gardner wrote:
>
> 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
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


-- 
Simon MacMullen
RabbitMQ, VMware