Hi Graham,
> I have just discovered I am affected by
> https://issues.apache.org/jira/browse/QPID-5113# which is marked as fixed,
> is there a plan for a release any time soon for qpid?
Qpid releases are generally about 3 months apart, so it'll probably be December
or so before 0.26 is released
Hi all,
I have just discovered I am affected by
https://issues.apache.org/jira/browse/QPID-5113# which is marked as fixed, is
there a plan for a release any time soon for qpid?
Regards,
Graham
--
-
To unsubscribe, e-mail: use
c.
> -Original Message-
> From: Gordon Sim [mailto:g...@redhat.com]
> Sent: Friday, September 27, 2013 6:47 AM
> To: users@qpid.apache.org
> Subject: survey: c++ broker and queue depth statistics
>
> The c++ broker reports a queue depth in terms of total bytes, as well as the
> number of
On Fri, Sep 27, 2013 at 09:28:33AM -0400, Ted Ross wrote:
> Darryl,
>
> I added "Python Client (Wrapped)" to the component list.
Thanks, Ted.
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://ww
Darryl,
I added "Python Client (Wrapped)" to the component list.
-Ted
On 09/27/2013 09:09 AM, Darryl L. Pierce wrote:
Now that the Swigged Python library is out in the wild, at least in
Fedora, can we add a new component for reporting features and bugs to
differentiate them from the pure Pytho
On 09/27/2013 01:01 PM, Pavel Moravec wrote:
I would vote for (c) option.
Thanks, Pavel!
Negs:
- "backward incompatible" change
Pros:
- the incompatibility requires just a change in one type of number during one
upgrade
And I'd note this is a worst case scenario also. For many current use
On 09/27/2013 12:52 PM, Jakub Scholz wrote:
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 queu
Now that the Swigged Python library is out in the wild, at least in
Fedora, can we add a new component for reporting features and bugs to
differentiate them from the pure Python bindings?
--
Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
Delivering value year after year.
Red Hat ranks #1
I agree with Pavel and Jakub. Tying the "bytes" depth as closely as
possible to actual memory consumption is probably a good thing. We
could even consider counting the message overhead (the memory used that
is not part of the actual message).
-Ted
On 09/27/2013 08:01 AM, Pavel Moravec wrote
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"
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 a
This is a cross-compiled version running on an embedded ARM processor.
I'm seeing odd behaviour in reacquiring a connection to a remote unit that's
rebooted. I have created a MessageSender object that's managing all the
qpid objects and it's created a connection, session and sender to a topic on
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 includin
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 th
14 matches
Mail list logo
