Hi,
I am using Qpid JMS to send messages to a C++ broker which will then be
received by a C++ client. My JMS client connects to the broker using a
different authenticated user than the C++ client. The issue I am running into
is that when the JMS client sends a message, it sets the user_id pro
On 06/18/2014 06:39 PM, Fraser Adams wrote:
On 18/06/14 09:13, Gordon Sim wrote:
On 06/17/2014 10:35 PM, smartdog wrote:
It is the qpid c++ broker. The BDB store is used. Is there a way to
improve
the performance while preserving the persistence?
Can you send messages in batches? I.e. don't m
On 18/06/14 09:13, Gordon Sim wrote:
On 06/17/2014 10:35 PM, smartdog wrote:
It is the qpid c++ broker. The BDB store is used. Is there a way to
improve
the performance while preserving the persistence?
Can you send messages in batches? I.e. don't make every send synchronous.
A synchronous s
An example of a deleted statistic that was restored is in
https://issues.apache.org/jira/browse/QPID-5355
The accepted restoration described the statistic as Deprecated:
{noformat}
+
+
{noformat}
-Chuck
- Original Message -
> From: "Justin Ross"
> To: users@qpid.apache.org
> Sent:
On Wed, Jun 18, 2014 at 8:01 AM, Pavel Moravec wrote:
> Hi all,
> getting some queue statistics, I realized there are legacy stats like:
>
> byteFtdDepth
> byteFtdDequeues
> byteFtdEnqueues
> msgFtdDepth
> msgFtdDequeues
> msgFtdEnqueues
>
> that refer to already removed flow-to-disk queue limit
Hi all,
getting some queue statistics, I realized there are legacy stats like:
byteFtdDepth
byteFtdDequeues
byteFtdEnqueues
msgFtdDepth
msgFtdDequeues
msgFtdEnqueues
that refer to already removed flow-to-disk queue limit policy. As far as I
checked, the code changing the stats is a dead code.
I
On 06/17/2014 10:35 PM, smartdog wrote:
It is the qpid c++ broker. The BDB store is used. Is there a way to improve
the performance while preserving the persistence?
Can you send messages in batches? I.e. don't make every send synchronous.
A synchronous send will always be a little slower and
Durable messages will be everytime (much) slower to process than transient, as
disk I/O operations are much slower than keeping the message just in memory.
I would rather attempt to improve general I/O performance of the
filesystem/disk you use for journals. I.e. older versions of ext4 filesyste
