It is the qpid c++ broker. The BDB store is used. Is there a way to improve
the performance while preserving the persistence?
qpidd.conf
data-dir=/var/spool/qpid
mgmt-enable=yes
load-module=/usr/local/phonefactor/bin/legacystore.so
load-module=/usr/local/phonefactor/bin/qpid/store/store.so
>From
I don't think that the client library (Proton) has anything to do with
this disparity of latency. It is simply waiting for settlement from the
broker because of the synchronous send.
What kind of broker are you using and how is the message store on it
configured?
-Ted
On 06/17/2014 02:10 PM, sm
On 17/06/2014 18:38, Andrew Stitcher wrote:
On Mon, 2014-06-16 at 18:19 +0100, CLIVE wrote:
Already created QPID-5828 to cover these issues (plus some others). I
have also attached several boost unit tests that help demonstrate the
problems.
Do you have some way to produce unit tests for the lo
With Proton c++ client, it seems sending an undurable message to a qpid queue
takes 1-3ms, while sending a durable message takes static 1000ms. Is it by
design? Why does it take so much time?
My code:
pn_message_set_durable(message, true);
for(i=0;i<10;i++){
gettimeofday(&start, NULL);
pr
On Mon, 2014-06-16 at 18:19 +0100, CLIVE wrote:
> Already created QPID-5828 to cover these issues (plus some others). I
> have also attached several boost unit tests that help demonstrate the
> problems.
Do you have some way to produce unit tests for the lock issues? (I'm
assuming not, but if so
Hi
I have this scenario:
Two federated qpid A and B, in different machines, with routes ( and links)
between them.
Without deleting any configuration I've remove qpid B and added a qpid C.
>From this moment I couldn't configure qpid C with routes between A and C
>because qpid A was returning
Hi,
I was having some problems to post to the mailing list, so I ended up
opening the DISPATCH-59.
I found some problem when a connector configured router quickly reconnects
to a listener router. Something to do with the router already being in the
linkset collection and then the initial MAU proc
Aha, x-amqp-to works a treat.
I'd tried adding the x-opt-qd.to option mentioned here
https://qpid.apache.org/releases/qpid-dispatch-0.2/book/amqp-mapping.html
but in retrospect that does look more like an internal router property.
Many thanks!
On 17 June 2014 13:29, Ted Ross wrote:
> Hi Chris
Hi Chris,
You may have run afoul of
https://issues.apache.org/jira/browse/DISPATCH-1 which was fixed after 0.2.
Spout doesn't set the "to" field in the messages it sends, it puts the
address in the target of the link.
You can work around this by adding the following to the spout command
line: -
Hi,
I'm trying to get an example of a multi-hop topology working with
qpid-dispatch 0.2 built against qpid-proton 0.28. The scenario is probably
most simply described by plagiarising the config files from the
tests/config-3-linear directory, which sets up a series of 3 sequentially
connected route
10 matches
Mail list logo
