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. -- 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
