On 03/02/14 23:31, Robbie Gemmell wrote:
More of an observation/question for all, than reply to youFraser.... I
noted the following while I was skimming:


" These sends resulted in the following messages from drain:

1. From Proton Messenger send:
Message(properties={x-amqp-absolute-expiry-time:0, x-amqp-creation-time:0,
x-amqp-group-sequence:0, x-amqp-to:amqp://localhost/amq.fanout},
content='Hello World!')

2. From JavaScript Proton send:
Message(properties={x-amqp-absolute-expiry-time:0, x-amqp-creation-time:0,
x-amqp-group-sequence:0, x-amqp-to:amqp://localhost:5673/amq.fanout},
content='Hello World!')

3. From qpid::messaging spout:
Message(properties={spout-id:cf6c9ee4-93e8-42cf-af6b-cfff1632e5e8:0},
content='Hello World') "


This suggests that Messenger is encoding the absolute-expiry-time,
creation-time, and group-sequence fields of the Properties section with the
value 0 if they arent specified, rather than omitting them (using nulls if
necessary to allow for later fields, or omitting them entirely if they are
trailing). I'm assuming the same thing would happen to e.g ttl if a header
section was required.

Does that seem accurate, and if so is it something we should look to
prevent?

So this happens in message.c in
int pn_message_encode(pn_message_t *msg, char *bytes, size_t *size)

......

  err = pn_data_fill(msg->data, "DL[CzSSSCssttSIS]", PROPERTIES,
                     msg->id,
                     pn_string_get_bytes(msg->user_id),
                     pn_string_get(msg->address),
                     pn_string_get(msg->subject),
                     pn_string_get(msg->reply_to),
                     msg->correlation_id,
                     pn_string_get(msg->content_type),
                     pn_string_get(msg->content_encoding),
                     msg->expiry_time,
                     msg->creation_time,
                     pn_string_get(msg->group_id),
                     msg->group_sequence,
                     pn_string_get(msg->reply_to_group_id));


so basically it looks like it populates *all* standard PROPERTIES even if they aren't *explicitly* set.

I commented that based on what I was seeing it looked like qpid::messaging wasn't using Proton's message code 'cause qpid::messaging only seems to be sending properties that have been explicitly set.



It's probably worth aiming for consistency, but TBH I'm an awful lot more concerned that Proton Messenger doesn't seem to have a mechanism for setting link configuration and thus I couldn't use it for most of my more interesting examples, which was a shame.

Nobody has yet confirmed nor refuted whether this observation is correct. I'd like to know for sure and if that stuff isn't supported I'd love to know what the intentions are.

Cheers,
Frase





---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Reply via email to