On Fri, Feb 15, 2013 at 03:50:28PM +0000, Gordon Sim wrote: > On 02/15/2013 03:29 PM, Steven Hardy wrote: > >Well, no - this is only addressing half of the problem - on the receiver > >side the binary buffer gets returned to the user as a string, but it's not > >converted back to the original format - so the message is corrupted and we > >have no way of knowing that conversion from binary is required. > > You could check the size and decode anything over 2^16... but I > agree that is not ideal. I'll consult some more on that(!)... > > >See my attached revised reproducer - maybe I'm missing something, but I > >don't see how we can detect the _context_aws_creds key has been binary > >encoded on the receiver side. > > > >It seems to me that the problem here is python-qpid encoding individual > >dict/map keys - wouldn't it be better to just dump the whole dict to a > >string (ie json), > > You can certainly do that. Just set the content to the original json > string and send it.
Aha! I've realized that if I send the contents as a nested dict (instead of a dict containing a json serialized dict) the problem does not occur. Thanks for helping me work through this - your comment on QPID-4583 "It is an AMQP 0-10 encoded map" made me look at the spec again, which says "The value is encoded according to the rules defined by the type code for that entry" - so I can see now that any string values in the dict will need to be < 65535 bytes long, but if I send the json template as a dict it will work. I'll add a comment to the JIRA ticket so it can be closed, thanks again! I still find it interesting that we don't hit this problem on rabbitmq, but I guess that may have to be a mystery that can be solved another day ;) Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
