I forgot to mention that you might also mitigate this problem with
slow-consumer detection [1] so that if a consumer stalls and does not ack
messages in the configured time then it will be disconnected potentially
clearing the condition that was causing it to stall in the first place.
Justin
[1]
> We haven't tried this yet, mainly because of concerns about high memory
consumption. One of the consumers of large messages, pulls messages from
the queue, at a speed about 3 times less than they are produced.
My suggestion is only to gain more information about the problem. If
eliminating large
We have experienced the similar problems.
1. Some of consumers (listens the same JMS topic) would stop receiving messages
while others are working perfectly. We haven't identified the root cause but
figured a way to resolve it. We institute (JMS consumer) a time-bound read and
track the last ti
As far as I can tell this is the same message you sent a few days ago. You
can find my response to that message here [1].
Justin
[1] https://lists.apache.org/thread/p2lxw22nhwhq015lvjn0kqtxdsdj3vx4
On Tue, Jan 3, 2023 at 7:13 PM John Lilley
wrote:
> Greetings!
>
>
>
> In our app, we have a lo
Greetings!
In our app, we have a lot of batch “jobs”, each of which stands up an RPC
service on a unique queue. However, when jobs quit, clients may still try to
communicate and I don’t want this to hang, I want clients to see an error
reply. To this end, I am implementing a “fallback” servic
We have experienced the similar problems.
1. Some of consumers (listens the same JMS topic) would stop receiving messages
while others are working perfectly. We haven't identified the root cause but
figured a way to resolve it. We institute (JMS consumer) a time-bound read and
track the last ti
Also wanted to add that you need to experiment with the client settings. We
found that certain combinations of caching and transaction settings cause
the client to run great for a while, like a day in our case then
progressive degrades until becoming stalled with no errors or exceptions in
the clie
Just want to add my experience with issues like this but im still at the
learning level with Artemis.
Watch out for a delivering count with the address not getting ACQs as this
has always meant a problem with the consumer or a poison message, in our
experiences.
Also redeliveries and/or duplicates
Hi,
In our installation we use Artemis 2.27.1 embedded into SpringBoot 2.7.6.
Recently two separate Artemis clusters in different DCs have been joined using
federation queues (both downstream and upstream mode). Since that time, we
observe heap memory hits from time to time. Looks this could be
