cshannon commented on PR #1364: URL: https://github.com/apache/activemq/pull/1364#issuecomment-2535866454
@kenliao94 - In talking with @tabish121 there is one more wrinkle that I think also makes this more challenging if we are sticking strictly to the spec regarding the completion listener: https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1#use-of-the-completionlistener-by-the-jakarta-messaging-provider > 7.3.8. Use of the CompletionListener by the Jakarta Messaging provider > A session will only invoke one CompletionListener callback method at a time. For a given MessageProducer or JMSContext, callbacks (both onCompletion and onException) will be performed in the same order as the corresponding calls to the asynchronous send method. The issue here is that if a producer is sending messages to different destinations and/or with different modes (persistent/non persistent) then while the broker will handle the ordering correctly for each destination, it's possible and likely that the client will receive the responses out of order and end up completing the callbacks out of order. This is because the ActiveMQ client tracks the async requests in a [map](https://github.com/apache/activemq/blob/645dd999644c49a0b28b3dbda3b04c7098fafc54/activemq-client/src/main/java/org/apache/activemq/transport/ResponseCorrelator.java#L42) and just completes them as it receives them. In order to honor the spec for this section you would have to modify things to hold responses and not invoke those callbacks immediately if there were previous outstanding calls that had not been completed which is of course different than what the current behavior of the client is. There is a good example of the complexity in handling this in the Qpid JMS JmsSession class where they track all their async request completions in a queue: https://github.com/apache/qpid-jms/blob/2d799c153a6b51f07a4c9ccec4a8751598183733/qpid-jms-client/src/main/java/org/apache/qpid/jms/JmsSession.java#L139 so that things are processed in order. I suppose there could be a discussion on whether this requirement really needs to be met or not for the client but if the intention is to implement the spec then it should probably be followed 100%. The other issue of course is that this behavior is a bit different than the existing async behavior that the client supports (obviously completing as soon as it gets a response back) so then we'd have to decide if we also need to preserve the old way for the existing API. -- 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
