[
https://issues.apache.org/jira/browse/ARTEMIS-3610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459797#comment-17459797
]
Gary Tully edited comment on ARTEMIS-3610 at 12/15/21, 12:04 PM:
-----------------------------------------------------------------
The current behaviour where it fires immediately is just wrong from a jms
durable send point of view, it is essentially a lie. However it is a very fast
way to get bytes to the broker. The network can be saturated and the journal
buffer can batch writes and syncs. In a controlled stable environments it can
be very performant. This can be beneficial.
Maybe it is just a case of documenting that the completion listener callback
without a confirmationWindowSize set is a suggestion/lie, and if the user is
interested in the true state of the message on the broker, they need to
configure a confirmation window and await confirmations from the broker.
The produerWindowSize will still limit, and can block, message production if
the server does not grant credit.
was (Author: gtully):
I think the use of completion listener with a persistent message with default
(unset) confirmationWindowSize should behave as if confirmationWindowSize=1,
essentially blocking behaviour.
The current behaviour where it fires immediately is just wrong from a jms
durable send point of view, it is essentially a lie.
> Artemis's Core JMS 2 CompletionListener with persistent messages should work
> by default
> ----------------------------------------------------------------------------------------
>
> Key: ARTEMIS-3610
> URL: https://issues.apache.org/jira/browse/ARTEMIS-3610
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Major
>
> JMS 2 spec allow non-persistent messages sent to get CompletionListener's
> callback called without any response coming from the broker, but persistent
> ones should use CompletionListener relying on broker's responses.
> Right now if users won't configure confirmationWindowSize (that's -1 by
> default), they won't get *any* meaningful behaviour of CompletionListener
> both for persistent and non-persistent messages: we should provide a default
> configuration of confirmationWindowSize or just allow CompletionListener to
> work without configuring any, in order to let persistent messages to work as
> by JMS 2 spec.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
