[
https://issues.apache.org/jira/browse/AMQ-8324?focusedWorklogId=947763&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-947763
]
ASF GitHub Bot logged work on AMQ-8324:
---------------------------------------
Author: ASF GitHub Bot
Created on: 11/Dec/24 12:32
Start Date: 11/Dec/24 12:32
Worklog Time Spent: 10m
Work Description: 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.
Issue Time Tracking
-------------------
Worklog Id: (was: 947763)
Time Spent: 2h 10m (was: 2h)
> 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: 2h 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
