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).
The default is currently false. I.e. by default no distinction will be made at the API level between application properties and annotations, meaning that the behaviour, though different from the past couple of releases as far as 1.0 support goes, is similar to 0-10.
If anyone feels the default is wrong or there is a better way to handle this I'd be eager as always to hear from you and we can improve on what is now checked in.
--Gordon. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
