[
https://issues.apache.org/jira/browse/AMQ-8324?focusedWorklogId=947931&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-947931
]
ASF GitHub Bot logged work on AMQ-8324:
---------------------------------------
Author: ASF GitHub Bot
Created on: 12/Dec/24 01:36
Start Date: 12/Dec/24 01:36
Worklog Time Spent: 10m
Work Description: kenliao94 commented on PR #1364:
URL: https://github.com/apache/activemq/pull/1364#issuecomment-2537555045
@cshannon makes sense. Thank you for your through review!
Regarding 7.3.6 and 7.3.9: I will bring back the flag idea I mentioned in
the description. During my exploration, I used the exact approach as Qpid JMS,
add a setter method and an attribute to ActiveMQMessage. If that attribute is
true. It will throw exception. As stated in the `jakarta.jms.Message`
interface, message header getters can throw `JMSException`. The caveat is the
implementation `ActiveMQMessage` those methods don't throw exception. As a
result, when I declared throw in the implementation, it propagates out and
caused many compilation failure in even the MQTT packages. That being said, I
agree with your assessment that we need to prevent message headers and
properties being accessed so I need more work on that.
Regarding 7.3.3 and 7.3.8: I think I see your points now. Basically ordering
within same destination and same delivery mode is already honored by the
broker. So we are on the same page that 7.3.3 is already met as is. However,
when it comes to 7.3.8, across destination from the same producer, the message
order is not honored and I think you are right with the example you provided.
When I looked at it initially, it is a map and there's no mechanism in the
transport layer that make sure it is honored but I forgot about that case. I
will push a new revision ASAP.
Regarding legacy vs compliant mode, in this PR, it is differentiated by what
API the client application uses. If the application uses the Jakarta Messaging
API, async send with CompletionListener, it will get the behavior as described
in the spec, I.E compliant mode. If the client application decides to cast the
`MessageProducer` to `ActiveMQMessageProducer` and uses the AsyncCallback API,
then it will get the legacy mode. In our public doc, we will mark AsyncCallback
as deprecated and make a statement that in ActiveMQ 6 we will support both but
encourage the use of compliant mode. ActiveMQ 7, we will remove it.
Issue Time Tracking
-------------------
Worklog Id: (was: 947931)
Time Spent: 3h 40m (was: 3.5h)
> 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: 3h 40m
> 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
