[
https://issues.apache.org/jira/browse/IGNITE-25945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18065613#comment-18065613
]
Roman Puchkovskiy edited comment on IGNITE-25945 at 3/13/26 11:07 AM:
----------------------------------------------------------------------
Why the change was made the way it was made.
#. Originally (when each sent message was acked individually), latency was
good, but we were sending too many ack messages and spent too much resources on
that
#. Batch acks were introduced
#. As a result, send latency became too high, and SQL relies on sends (no
problems with invokes arised as the sender awaits for a response anyway)
#. So in this ticket, the following was implemented: send future is completed
as soon as a write to the channel completes; but acks are still used internally
(in recovery descriptors) to correctly restore logical connection and guarantee
unacked message delivery
#. That's why we had to abandon the old guarantee 'send future is only
completed when the message is acked by the recipient): it turned out, we don't
need it.
#. That's why we had to adjust the corresponding tests
After this change, send future completion does not guarantee that the message
was delivered to the recipient. This guarantee wasn't used by our protocols;
also, it wasn't strong enough as it did not guarantee that the message was
actually *handled* by the recipient (if this guarantee is needed, invoke should
be used). With all that, delivery is as reliable as it was before (as after a
physical connection termination, we still resend only the non-acked messages).
was (Author: rpuch):
1. Originally (when each sent message was acked individually), latency was
good, but we were sending too many ack messages and spent too much resources on
that
2. Batch acks were introduced
3. As a result, send latency became too high, and SQL relies on sends (no
problems with invokes arised as the sender awaits for a response anyway)
4. So in this ticket, the following was implemented: send future is completed
as soon as a write to the channel completes; but acks are still used internally
(in recovery descriptors) to correctly restore logical connection and guarantee
unacked message delivery
5. That's why we had to abandon the old guarantee 'send future is only
completed when the message is acked by the recipient): it turned out, we don't
need it.
6. That's why we had to adjust the corresponding tests
After this change, send future completion does not guarantee that the message
was delivered to the recipient. This guarantee wasn't used by our protocols;
also, it wasn't strong enough as it did not guarantee that the message was
actually *handled* by the recipient (if this guarantee is needed, invoke should
be used). With all that, delivery is as reliable as it was before (as after a
physical connection termination, we still resend only the non-acked messages).
> Acknowledge messages in batches
> -------------------------------
>
> Key: IGNITE-25945
> URL: https://issues.apache.org/jira/browse/IGNITE-25945
> Project: Ignite
> Issue Type: Improvement
> Reporter: Roman Puchkovskiy
> Assignee: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.1
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Currently, we acknowledge each acknowledgeable message individually. Instead,
> we should acknowledge them in batches (like it's done in Apache Ignite 2).
> This means that acknowledge on timeout is also needed for situations when a
> batch remains incomplete for some time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
