[rabbitmq-discuss] RabbitMQ appears to send 0-9-1 formated message to 0-8 client

[Elias Levy]

On Wed, Apr 4, 2012 at 2:57 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> This is interesting, but I have a hard time believing it I'm afraid.
>
> 1) basic.deliver has a "redelivered" field in both AMQP 0-8 and 0-9-1 (see
> line 2957 of the 0-8 XML).
> 2) In both versions of the standard, redelivered is of type "bit".
>

Thank for pointing this out. I searched the 0-8 PDF and found no mention to
it, but I see it in the XML now.  That will show me for not searching all
of the documentation.

3) I don't recall any of the AMQP codec code changing since 2.5.1.
> 4) This is really basic stuff, any client that couldn't unpack
> basic.deliver would be so broken as to be useless.
>
> So I wonder what might really be happening?
>
> I note that Net::AMQP throws that exception in a function called
> unpack_field_table(). But the method fields aren't in a table.
>
> We do however create a table in the message headers that has a key
> "redelivered". In federation. You haven't recently started using federation
> by any chance?
>

Bingo.  We added a federated exchange for forward some messages from our
prod env to the dev env for testing.


> And we make that field boolean, because that's what it is. But from the
> AMQP 0-8 spec:
>
> 4.2.5.5  Field Tables
>
> Field tables are long strings that contain packed name 赳alue pairs. Each
> name 赳alue pair is a structure that provides a field name, a field type,
> and a field value.  A field can hold a tiny text string, a long string, a
> long signed integer, a decimal, a date and/or time, or another field table.
>
> Damn it.
>

Yes,  that's the section I was reading in the 0-8 PDFs.

So I guess we need to do some field type mapping when talking to 0-8
> clients. I had hoped the 0-8 clients would have gone away by now...
>

You and me both.

Elias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120404/623761ce/attachment.htm>