On 15/05/14 13:28, Tomáš Šoltys wrote:
Hi all

I have slightly modified an example send.c file to send message containing 1024 bytes.
Above will result in zero sized message on the receiver side.

Is this an intention or a bug?


Tomáš Šoltys
I doubt there's a *deliberate* limit ;-) , my money is that the issue you're observing is actually on the receiver side. I've just tried sending an 11K string using the JavaScript binding I'm working on and that transfered OK.

Assuming that you are using recv.c in examples the bit of code that will interest you is:

char buffer[1024];
size_t buffsize = sizeof(buffer);
pn_data_t *body = pn_message_body(message);
pn_data_format(body, buffer, &buffsize);

format takes the encoded data and displays it in a human readable format, you pass in a buffer and you get the actual number of bytes back in the reference parameter - in this case buffsize.

As you can see in recv.c the buffer is a *fixed* 1024 byte buffer.

A more robust implementation would use a dynamically allocated buffer and check the return value of pn_data_format for PN_OVERFLOW and resize the buffer.

FWIW here's the implementation of format I've used in the JavaScript binding - it's somewhat relevant as it the binding actually cross-compiles proton-c to JavaScript so I need to handle the C style memory allocations in order to create something idiomatically JavaScript.

* Format the encoded AMQP Data into a string representation and return it.
* @method format
* @memberof! proton.Data#
* @returns {string} a formatted string representation of the encoded Data.
_Data_['format'] = function() {
var size = 1024; // Pass by reference variable - need to use setValue to initialise it.
while (true) {
setValue(size, size, 'i32'); // Set pass by reference variable.
var bytes = _malloc(size); // Allocate storage from emscripten heap.
var err = _pn_data_format(this._data, bytes, size);
var size = getValue(size, 'i32'); // Dereference the real size value;

if (err === Module['Error']['OVERFLOW']) {
size *= 2;
} else {
var string = Pointer_stringify(bytes);
return string;

So as you see I'm checking for OVERFLOW and if I see it I free the original buffer and try again with a buffer of twice the size. The Python and Ruby bindings do pretty much the same.

As it happens as I was typing this I actually tried messing a bit more, when I sent a string of length 22277 it seems to be received OK but my producer doesn't seem to be terminating correctly, when I double it again to 44554 I don't seem to be receiving. That's quite possibly a bug in my binding - this is the first time that I've tried something so large however I have seen the odd
[0x550ef8]:ERROR amqp:connection:framing-error connection aborted
[0x550ef8]:ERROR[-2] connection aborted

and the underlying implementation is proton-c so it is possible that there's an issue there, I don't know how far the core proton-c testing has gone with respect to large messages, somebody like Rafael Schloming would hopefully know.


Reply via email to