[
https://issues.apache.org/jira/browse/AMQ-8324?focusedWorklogId=947911&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-947911
]
ASF GitHub Bot logged work on AMQ-8324:
---------------------------------------
Author: ASF GitHub Bot
Created on: 11/Dec/24 23:19
Start Date: 11/Dec/24 23:19
Worklog Time Spent: 10m
Work Description: cshannon commented on PR #1364:
URL: https://github.com/apache/activemq/pull/1364#issuecomment-2537400365
@kenliao94 - I think 7.3.3 is already handled by the broker as it should
enforce the order across each destination and between mode (persistent/non
persistent) but we can test.
My concern the last few comments has to do with 7.3.8 which refers to the
order that the completion listeners complete and that is the thing that would
not be handled right now. The listeners would complete as the requests to the
broker complete, so there is no guarantee the client will complete them in the
order as 7.3.8 requires across different destinations.
For example, let's say a producer sends 5 messages to 5 different
destinations async (anonymous producer). I believe the current behavior of the
client is that the completion callback would be executed for each of the 5 sent
messages whenever they are received back from the broker. Because you are
publishing to 5 different destinations, and because the broker does not enforce
any kind of order across destinations, it's possible the producer will receive
back the acks for the sent messages in a different order then they were sent.
So this could lead to something like the callback for the 3rd published message
being executed before the first one. We would need some way for the client to
keep track of the order and hold off completing.
The caveat is I _think_ this is the current behavior. I would need to double
check it but I don't think there's anything preventing the broker from
responding back in a different order if the messages are published to different
destinations.
Regarding 7.3.5 it sounds like @mattrpav asked a question about it so I'm
not sure if it can be skipped.
Regarding 7.3.6 I missed this when originally reviewing the PR and I read
into the spec more and your explanation and I'm not sure I agree. The spec says
that you "may" throw an exception so that part is optional but I would argue
it's preferred. What I'm reading is that you still would need to prevent the
fields/properties from being accessed even if you didn't. I do not agree with
your assessment that it is somehow messy code or the applications job. The
simplest thing to do is the thing you didn't do, and that is just have a flag
that is set that sets the mode and if the setter is allowed to be accessed and
if it isn't because the competition is pending you throw an exception. Here is
where Qpid JMS enforces this:
https://github.com/apache/qpid-jms/blob/2d799c153a6b51f07a4c9ccec4a8751598183733/qpid-jms-client/src/main/java/org/apache/qpid/jms/message/JmsMessage.java#L461-L481
Qpid JMS is a pretty good open source reference point in general to refer
to. While it's AMQP, it's a good starting point for tips on how to handle the
spec.
Issue Time Tracking
-------------------
Worklog Id: (was: 947911)
Time Spent: 3h 20m (was: 3h 10m)
> 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 20m
> 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
