This was caused by ARTEMIS-4582 [1]. I've opened ARTEMIS-4742 [2] and sent
a PR [3] to address the problem.
To be clear, this has nothing to do with replication or load/throughput.
It's just a buffer formatting issue caused by a configuration change.
Justin
[1]
Erwin responded [1] almost a week ago now. Did you have additional
questions?
Justin
[1] https://lists.apache.org/thread/9h2sdp7y5kg05p8qy77d5clnn8v1jkk2
On Mon, Apr 22, 2024 at 9:00 AM Naveen kumar wrote:
> Hi Team,
>
> Any update on below please ?
>
> Regards,
> Naveen
>
> > On 16 Apr
Okay,
I am answering my own question after some more research.
The problem was the consumerWindowsSize of the client consumers. This was set
to 0 leading to no buffering at all and a server round-trip for each retrieve
call.
After increasing window size to half a megabyte, the performance
Hi Team,
Any update on below please ?
Regards,
Naveen
> On 16 Apr 2024, at 11:59 AM, Naveen kumar wrote:
>
> Hi Team,
>
> We have the below question on temporary queues in Artemis MQ in eks . Could
> you please help us with answer for the below ones,
>
> 1. When are temporary queues used
Hello Team,
I have a question regaring Artemis.
We have two different clusters, that run more or less independently.
But for some events and requests there should be a transparency between
the clusters.
I thought that Adress Federation
Good morning group.
We encounter a performance issue with ActiveMQ Artemis. The system was formerly
a JBoss HornetQ installation and was migrated to AciveMQ Artemis and with
HornetQ we had no issues at all
The performance issue is about a multicast address with a single queue that has
