I would vote for (c) option. Negs: - "backward incompatible" change
Pros: - the incompatibility requires just a change in one type of number during one upgrade - calculation of message size should be unified - assume a queue enqueuing messages from 1.0 and 0-10 client - limiting queue in "size" units is IMHO useful to limit memory consumption of the queue - where counting message headers in the limit makes more sense Kind regards, Pavel ----- Original Message ----- > From: "Gordon Sim" <g...@redhat.com> > To: users@qpid.apache.org > Sent: Friday, September 27, 2013 1:04:17 PM > Subject: Re: survey: c++ broker and queue depth statistics > > 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-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
