[
https://issues.apache.org/jira/browse/ARTEMIS-3507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17426313#comment-17426313
]
Justin Bertram commented on ARTEMIS-3507:
-----------------------------------------
It would certainly be possible to add a timeout so that un-acked messages in
the batch are acked eventually regardless of the batch size. I wouldn't want to
add anything "smarter" than that as I don't think it's likely to provide a good
return on the investment. I think that adding much complexity here is likely to
increase the likelihood of bugs and counterintuitive behavior. Also, it's worth
noting that what is "smarter" for one use-case is not necessarily "smarter" for
another so any changes here would not impact the default behavior. They would
be optional so-as to not break users who rely on the existing behavior.
> Smarter batching of acks
> ------------------------
>
> Key: ARTEMIS-3507
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3507
> Project: ActiveMQ Artemis
> Issue Type: Wish
> Components: Broker
> Affects Versions: 2.17.0
> Reporter: Lasse Lindgård
> Priority: Major
>
> Using the default settings and the CORE api, I create a long running
> ClientSession, with a MessageHandler.
> Now when I consume messages I can see that the message acks are batched and
> delivered to the broker as configured in ackBatchSize. And the Message Count
> in the management console are only decreased when the acks are actually sent.
> In a low traffic scenario, with long running consumers, that might cause the
> acks "never" be sent or only to be sent on restarting the services.
> I wish that that could be improved somehow. And not by setting
> ackBatchSize=0. But in some clever way make sure that the acks are sent, even
> when the traffic is lower.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
