qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Moravec <pmora...@redhat.com>
Subject Re: survey: c++ broker and queue depth statistics
Date Fri, 27 Sep 2013 12:01:32 GMT
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" <gsim@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

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


Mime
View raw message