Hello,
I am struggling to get my client to failover as I'd expect in my cluster.
I am expecting that when 1 node fails my client should jump to that node's
backup in the topology. However, what I see occur is my client jumps to another
primary node instead. Sometimes I do see things behave as e
I agree with Anton here 100%.
Netty uses direct memory for performance reasons. If you disable it there
will certainly be performance trade-offs. Whether that really impacts you
depends on your use-case.
Also, keep in mind that if Netty doesn't use direct memory it will use the
JVM's heap instead
In absolute terms AIO is faster than NIO. That's the whole reason we
created the activemq-artemis-native integration layer.
However, whether this difference actually impacts your deployment depends
on whether disk writes are a bottleneck. Therefore, it's really impossible
for us to answer this que
Send a blank email to users-unsubscr...@activemq.apache.org to unsubscribe
from ActiveMQ Users mailing list, for further details see
https://activemq.apache.org/contact
On Thu, 20 Feb 2025 at 11:15, 23F3000346 NASHEETA FARZANA <
23f3000...@ds.study.iitm.ac.in> wrote:
> Please unsubscribe me from
Please unsubscribe me from this mailing list
On Thu, 20 Feb, 2025, 3:15 pm Anton Roskvist, wrote:
> Sorry, but to my knowledge that is almost impossible to say for sure, as
> it's highly dependent on your specific use case and setup. As before
> though, if you can safely try it out, it might hel
Sorry, but to my knowledge that is almost impossible to say for sure, as it's
highly dependent on your specific use case and setup. As before though, if you
can safely try it out, it might help in narrowing down the source of the issue.
I'd really like to reiterate that version upgrades to any p
Ok,
In case the problem is direct memory
Do you think disable netty direct memory would have a serious impact on
performance?
E.g.
-Dio.netty.noPreferDirect=true -Dio.netty.maxDirectMemory=0
-Dio.netty.allocator.type=unpooled
On Thu, Feb 20, 2025 at 10:47 AM Anton Roskvist wrote:
> Hi,
>
> I thi
Hi,
I think the point would be that if possible, the idea would be to try the same
conditions against a more recent version of the broker. All else being equal,
this would rule out any and all issues that might already have been addressed
in the roughly 3000 commits since 2.14.0. Same could app
