I had assumed that messages were being processed, just not as fast as you
wanted (and the producer got limited to the rate at which the consumer
processed them), but you said the word "stuck" several times. Which is it?
Are you not processing messages, or are you not processing messages
quickly? I
> I'm referring to the Artemis User Manual p.324...Does this duplicate
detection work with the AMQP protocol?
Yes. The duplicate detection described in the ActiveMQ Artemis User Manual
is supported for AMQP clients when using Artemis 2.8.0 and newer (see
ARTEMIS-2294 [1]).
> If so: is it the same
I'm not sure that anything you've described clearly indicates that the
problem was that ActiveMQ failed to deliver the messages, rather than that
the Python client failed to ack the messages.
Are you able to reproduce the problem reliably enough to be able to use
Wireshark or similar to analyze th
It appears that your consumer isn't keeping up with your producer(s),
filling the persistent store, which slows your producer(s) to the rate at
which the consumer is consuming.
Your options are:
* Do nothing, and let it complete at the current rate.
* Speed up consumption, either by adding consume
I'm referring to the Artemis User Manual p.324
Does this duplicate detection work with the AMQP protocol?
If so: is it the same property field that has to be set: _AMQ_DUPL_ID? (why not
just use the message-ID?)
Where does this property value have to be set in the AMQP message?
Hi:
I have similar issues (
http://activemq.2283324.n4.nabble.com/Persistent-store-is-Full-100-of-107374182400-Stopping-producer-td4740024.html).
My activemq broker was mediating the transfer of millions of records, which
I was importing via Apache Camel (running on a
Karaf instance).
I am curren
