On 09/02/2013 12:26 PM, Gordon Sim wrote:
On 08/30/2013 11:30 AM, Jakub Scholz wrote:
Hi,
The JIRA QPID-4591 added the queue level sequencing. I played with it with
the 0.24RC3 release and it seems it doesn't work properly with AMQP 1.0
producers (C++ / Qpid Messaging API).
My queue is configured with following option:
u'qpid.queue_msg_sequence': u'queue.sequence'
The connection which sends a message into this queue seems to be closed due
to the amqp:internal-error:
[0xda1200:0] <- CLOSE @24 [@29 [:"amqp:internal-error", "Expected
descriptor of type ulong or symbol; found ", null]]
[0xda1200:0] <- EOS
2013-08-30 13:51:18 [Network] debug localhost:20000 decoded 107 bytes from
107
Exception: Connection closed by peer
2013-08-30 13:51:18 [Messaging] debug [127.0.0.1:39092-localhost:20000]
TcpTransport closing...
2013-08-30 13:51:18 [Messaging] debug [127.0.0.1:39092-localhost:20000]
Socket closed
2013-08-30 13:51:18 [Messaging] debug Driver stopped
And the broker log seems to complain about the type:
2013-08-30 13:51:18 [Broker] warning Exchange response cannot deliver to
queue response.ABCFR_ABCFRALMMACC1.b3458152-e106-42a6-9c8c-4984c08cff81:
Expected descriptor of type ulong or symbol; found
2013-08-30 13:51:18 [Broker] error qpid.127.0.0.1:20000-127.0.0.1:39092:
Expected descriptor of type ulong or symbol; found
Is this a known error or should I enter a JIRA for that?
This was a bug in the broker's handling of annotations. I have now fixed that, I
have also made a slight change to the way 1.0 messages are presented through the
qpid::messaging API.
In AMQP 0-10 any attributes the broker wanted to add to a message had to go in
the application properties. In AMQP 1.0 a distinction is made between
annotations (which intermediaries can add to) and the application properties
(which are set by the publishing application and can't be modified by
intermediaries). (This makes it clear what the original message was, and what
was added in transit, useful e.g. for message signing).
Previously when using AMQP 1.0 with qpid::messaging any annotations have been
made available through a nested property x-amqp-message-annotations or
x-amqp-delivery-annotations respectively.
However in a case like the one you mention above, this would force the
application logic to be slightly different when using 1.0 or 0-10, which is
something we are keen to avoid where possible.
So now, this behaviour is configurable through the nest_annotations connection
option. If true, then the behaviour is as it was previously, i.e. the
annotations are held in nested maps making it clear how they were encoded when
received. If false, annotations are just added to the message properties by the
receiving client (note this doesn't affect how the broker encodes messages with
annotations, just how the messaging API presents the data).
Having a connection option that changes how messages are presented seems
confusing and error prone.
Is it possible to present both to the client thus avoiding the need for a
configuration option? I.e. put annotations in the 1.0 nested maps _and_ in
message properties, and fold the 2 together to avoid duplicates when sending
messages? That way old & new code would both work without a config option.
Cheers,
Alan.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
