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?
Regards,
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']) {
_free(bytes);
size *= 2;
} else {
var string = Pointer_stringify(bytes);
_free(bytes);
this._check(err)
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.
HTH,
Frase
