Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1119
@clebertsuconic Exactly, it tries to block it for a finite amount of time
and only if not in the event loop: you've mentioned about stalling behaviours
and I've dig in the Netty code to find out a possible reason of it, finding
only 1 answer: maybe we share the I/O threads (via a pool?) with Netty and
calling ``writeAndFlush`` while on one of them.
Altought it is considered legal, IMHO is something that must be avoided
because it increases the risk to go OOM (it steals time to a thread that would
be happier while doing I/O stuff and releasing the sent ``ByteBuf``s) and it
will lead to unexpected infinite stalls...
It could be the key to solve other strange blocking behaviours happening on
replication too!
Anwers:
i - The original behaviour was already to perform a ``writeAndFlush``
there, but without applying any backpressure on the caller, streaming huge
messages with clusters (with 1 GB per msg) would lead anyway to log some warns
but then going OOM.
As you said we need to perform flow control in our codebase, but the
granularity allowed using Netty in idiomatic way couldn't be enough: a
"writable" flag is good for the most cases but not enough with very high
traffic with long burst of data (=== streaming huge messages in batches).
Maybe we need an API change, like returning a ``boolean`` on the
``NettyConnection::write`` method, in order to let the caller choose what to do
as part of its duties, but is weird ( as a user, I mean).
Monday we could talk about it better or I could ask on the forum for
feedbacks: solving it properly will improve Artemis a lot, I'm sure of it :+1:
ii - :100: No more crazy properties
Thanks Cleb!!!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
