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. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: gitbox-unsubscr...@activemq.apache.org For additional commands, e-mail: gitbox-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
