Hi Gordon/Rob,
I tried with asynchronous approach by setting the LinkSourceDurablity
to MixedMode (2) and LinkSenderSettle to MixedMode (2) and also setting the
Message Property SendSettled to true. A sender sending messages and receiver
sending messages. After sometime the sending application errors with error
"Maximum Depth Exceeded".
Also the consuming application hangs after it errors out on Sender. I have
restart the receiver process to consume rest of the messages. Is there anyother
configuration that I am missing
Also when creating the queue, I cannot set the limit policy to flow-to-disk
Sending message:link detached, reason: *Error{Condition:
amqp:precondition-failed, Description: resource-limit-exceeded: Maximum depth
exceeded on odimevent: current=[count: 204400, size: 104857200], max=[size:
104857600]
(/build/qpid-cpp-VLEObV/qpid-cpp-1.39.0/src/qpid/broker/Queue.cpp:1658), Info:
map[]} exit status 1
And if I try to config limit policy as to flow-to-disk, I get invalid choice.
Do I need configure anything else to enable that configuration.
qpid-config: error: option --limit-policy: invalid choice: 'flow-to-disk'
(choose from 'none', 'reject', 'ring', 'ring-strict')
Thanks & Regards,
Nancy
-----Original Message-----
From: Rob Godfrey [mailto:[email protected]]
Sent: Wednesday, May 19, 2021 8:55 PM
To: [email protected]
Subject: Re: Message Persistence in Qpid Broker C++ (1.39)
On Wed, 19 May 2021 at 17:04, Gordon Sim <[email protected]> wrote:
> On Wed, May 19, 2021 at 3:34 PM Namitha, Nancy <[email protected]> wrote:
> > Is Broker - J optimized for the below mentioned scenario.
>
> I believe the java broker will indeed perform better for synchronous
> publish. Best thing is to run a quick test though.
>
Broker-J does not rely on a flush timer, instead simply combining all DB
interactions that are running concurrently into a single write... So,
theoretically, for this particular case you shouldn't see the same sort of
latency... but as Gordon says you should really test with something that best
represents your actual expected workload. In general if you care about
performance then sending individual messages synchronously is not a good choice.
-- Rob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] For
> additional commands, e-mail: [email protected]
>
>
