ny additional overhead, to track demand across a cluster, or to move
> data to satisfy demand, is best minimised or removed altogether.
>
> I understand this is quite a different approach and considering the
> current setup works well in general, it may not be applicable, but it
>
ero would help
here. We're really looking for something like the cluster detecting there
are idle consumers and redistributing messages away form the broker with
the slow consumers.
Any pointers you can give me would be really appreciated.
Many thanks
Graham Stewart
assign a Dead Letter address for the internal
$.artemis.internal.sf queues? I am confused on whether we should or
should not do that.
Really appreciate any help you can give me on this.
Many thanks
Graham
On Mon, 30 Mar 2020 at 23:08, Graham Stewart
wrote:
> Thanks Domenico,
>
>
Thanks Domenico,
We have a heap dump from when this happened last week - it's large - 8GB.
We can see the internal queue that blew up was
$.artemis.internal.sf.cluster-prodemea-r186951.39.7adc9da9-6c30-11ea-b3c0-0050568f93e5
>From the heap dump that QueueImpl has
messagesReplaced 0
messagesK
realise this is big ask, but what other details can I provide that might
help diagnose the issue.
Many thanks
Graham Stewart