On 12/13/19 3:25 PM, Dirkjan Ochtman wrote:
On Thu, Dec 12, 2019 at 11:59 PM Timothy Bish <[email protected]> wrote:which is then encoded (not quite optimal, but seems to be correct per the spec) as [0, 0, 0, 70, 2, 0, 0, 0, 0, 163, 16, 97, 109, 113, 112, 58, 97, 116,116,97, 99, 104, 58, 108, 105, 115, 116, 208, 0, 0, 0, 38, 0, 0, 0, 14, 161,8,118, 120, 45, 119, 101, 98, 45, 48, 67, 163, 6, 83, 101, 110, 100, 101, 114, 64, 64, 64, 161, 3, 82, 80, 67, 64, 64, 64, 64, 64, 64, 64]Your encoding appears to go wrong when encoding the Role value as the encoding code appears to be (163) which is the encoding code for 'Char' while Role is expected to be a Boolean type.Thanks, I did miss that! This turned out not to fix the problem by itself. I previously didn't know exactly what to do with the way the spec documents source and target as being of the "*" type, but it turns out there are described types for both of these. Implementing these managed to get me to the next stage, where I get an attach performative returned from Artemis. I also discovered https://qpid.apache.org/amqp/type-reference.html, which is much easier to use than the spec PDF! Can you give me some pointers as to where in the source code this level of decoding happens for incoming message frames? That way, I might be able to better resolve similar problems in the future.
Artemis doesn't do the decoding itself, it uses the proton-j library from the Qpid project as the AMQP protocol engine and that is where frames are decoded and processed. The codec from proton-j is where you can get some ideas on how to properly encode and decode the AMQP performatives
https://github.com/apache/qpid-proton-j/tree/master/proton-j/src/main/java/org/apache/qpid/proton/codecYou can build some tooling for yourself using that library to validate that your own client emits and consumes AMQP data appropriately.
Kind regards, Dirkjan
-- Tim Bish
