Hi Gordon, Assuming there are no plans to abandon AMQP 0.10, I would say that in my opinion the option c) is worth the effort both on Qpid side as well as for the users side. The option d) seems to be unnecessary. At least with our use cases we never plan the queue sizes exactly to the last byte and I assume the difference between the 0.10 and 1.0 will be rather small.
Thanks & Regards Jakub On Fri, Sep 27, 2013 at 1:04 PM, Gordon Sim <g...@redhat.com> wrote: > On 09/27/2013 11:47 AM, Gordon Sim wrote: > >> The c++ broker reports a queue depth in terms of total bytes, as well as >> the number of messages. >> >> For 0-10 the bytes statistic is calculated by aggregating only the >> content size (i.e. the size of the body segment). For 1.0 it is the >> whole message including properties etc (i.e. the payload of the transfer >> 'performative'). >> >> So the size will be different depending on the protocol used in sending >> it and this difference can be quite marked. E.g. in an extreme case >> where there are many headers but no content, the bytes reported if sent >> over 0-10 would be 0 whereas if sent over 1.0 could easily be several >> hundred bytes. >> >> The question is what to do about this. The options are (a) accept that >> they are inconsistent between versions, (b) modify the 1.0 path to only >> record the application-data or (c) modify the 0-10 path to include the >> size of the header segment. >> > > I should point out that neither (b) or (c) give identical sizes for the > same application data due to minor differences in the two type systems. > However the difference would be fairly small and relatively fixed whereas > for (a) it can vary hugely depending on the exact message. > > An option (d) would be to try and come up with a scheme where the size > would be always identical. I'm not hugely keen on this as it would add > overhead (e.g. calculating the size of a set of 0-10 headers if encoded in > the 1.0 type scheme). > > > While (c) seems to me to be logical the most 'correct', it would be a >> difference in behaviour. It would mean for example that any queue limits >> would be hit earlier. One could argue that would be an improvement, but >> it may cause issues for systems when upgrading. >> >> The purpose of this mail is to solicit some feedback from users as to >> which of these options (or indeed other options that have not occurred >> to me) would be preferable. >> >> --Gordon. >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org> >> For additional commands, e-mail: users-h...@qpid.apache.org >> >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
