[
https://issues.apache.org/jira/browse/AMQ-8324?focusedWorklogId=947451&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-947451
]
ASF GitHub Bot logged work on AMQ-8324:
---------------------------------------
Author: ASF GitHub Bot
Created on: 10/Dec/24 00:58
Start Date: 10/Dec/24 00:58
Worklog Time Spent: 10m
Work Description: kenliao94 opened a new pull request, #1364:
URL: https://github.com/apache/activemq/pull/1364
**What is this PR about?**
Implemented Jakarta Messaging 3.1 spec, section 7.3
https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1#asynchronous-send
Jira ticket: https://issues.apache.org/jira/browse/AMQ-8324
Here an overview of how each requirement is satisfied:
**7.3.1 Quality of service**
This CR implements the feature in both Classic and Simplified API. It
references implementation of synchronous send and asynchronous send. It is
confirmed that the CompletionListener is triggered only when broker server
returns acknowledgement.
**7.3.2 Exceptions**
I trigger CompletionListener#onException if the onComplete throws an
exception.
**7.3.3 Message order**
This basically is "enforced" by the broker server. The requirement of 7.3.3
states that async messages sent to a particular destination should honor the
order when it comes to execution of associated CompletionListeners. In that
case, the broker server will send acknowledge the same order as the send
sequence, hence the execution of CompletionListener will follow the same order.
Will write a testcase for it.
**7.3.4 Close, commit or rollback**
The wait until all incompleted async send is Implemented by a CountdownLock
(I implemented it, it is similar to a CountDownLatch but it can be
incremented). Before the session is dispose, it will block until CountdownLock
is at zero. (If it is zero, then it is not blocked).
I also used a ThreadLocal object to set a "marker". So if the close,
rollback, commit methods are called on the session or producer in the same
thread of onComplete execution, it will throw an exception.
**7.3.5 Restrictions on usage in Jakarta EE**
I don't think we need to do this. I haven't found an example of it in the
codebase. Also from the spec, that is recommended but not mandatory. Asked on
the dev mailing list we can skip this requirement:
https://lists.apache.org/thread/r4fmmjcbgbgm0gw5mo4k3m4h3jzj8x8q
**7.3.6 Message headers**
This implementation won't throw the exception if the application try to
modify or access the message before the completionListenr is completed. Here
are the reasons:
1. The spec doesn't not demand the Jakarta messaging provider to throw an
exception ("may").
2. The primary reason for not supporting it is that it is the application
responsibility to honor "Applications which perform an asynchronous send must
take account of the restriction that a Message object is designed to be
accessed by one logical thread of control at a time and does not support
concurrent use." Let's say if the application construct the `Message` interface
using its own implementation (i.e not using `JMSContext#createMessage`), when
it is passed to the `send` method of `JMSProducer` the provider can't augment
the original object because the `jakarta.jms.Message` doesn't expose a method
to do so.
Note: I explored setting a flag in `ActiveMQMessage` to make it throw
exception when properties or headers are accessed. However, it kind of violates
the message object "one logical thread of control at a time" restriction and
need to throw JMSException and propagate out (messy code). I decide to not
implement the suggestion as it's not required by the spec.
**7.3.7 Restrictions on threading**
The execution of CompletionListener is in the transport layer (in another
thread). The application thread can continue to use the session after
performing an asynchronous send.
**7.3.8 Use of the CompletionListener by the Jakarta Messaging provider**
The execution of CompletionListener is in the transport layer (in another
thread)
**7.3.9 Restrictions on the use of the Message object**
See explanation at 7.3.6.
**How do I test this change**
1. I wrote unit tests.
2. I did many manual tests with a broker that simulates delay in sending
back ack. I used it to test multiple scenario including message orders are
honored according to 7.3.3, 7.3.7.
Issue Time Tracking
-------------------
Worklog Id: (was: 947451)
Time Spent: 1h 10m (was: 1h)
> Implement JMS 2.0 MessageProducer CompletionListener methods
> ------------------------------------------------------------
>
> Key: AMQ-8324
> URL: https://issues.apache.org/jira/browse/AMQ-8324
> Project: ActiveMQ Classic
> Issue Type: New Feature
> Reporter: Matt Pavlovich
> Assignee: Matt Pavlovich
> Priority: Major
> Labels: #jms2
> Fix For: 6.2.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> CompletionListener, etc
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
