[
https://issues.apache.org/jira/browse/AMQ-7309?focusedWorklogId=631180&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-631180
]
ASF GitHub Bot logged work on AMQ-7309:
---------------------------------------
Author: ASF GitHub Bot
Created on: 29/Jul/21 15:02
Start Date: 29/Jul/21 15:02
Worklog Time Spent: 10m
Work Description: gemmellr commented on pull request #682:
URL: https://github.com/apache/activemq/pull/682#issuecomment-889221247
> Yeah, so in that code it could be argued that the 'hasDelay' marker
variable (used 7 lines earlier in L907) should be used before calling the
setJMSDeliveryTime in the private setForeignMessageDeliveryTime method. That
method presumes that it should call the setJMSDeliveryTime even if there hasn't
been a DeliveryDelay specified.
>
It is set for every message sent because it should be. The [foreign] message
object may already have a populated JMSDeliveryTime value so even if there is
no delay being applied during this send call, the JMSDeliveryTime value should
still be stamped appropriately on the sent message object to ensure it is
correctly reflecting this send. (The 'hasDelay' variable is used for something
quite different, but obviously related).
> Either approach (throw UOE or swallow expected Delivery Delays) will
present downside to varying users and interests.
>
The message.set/getJMSDeliveryTime would just work as they are meant to,
allowing their use to simply report the values, and not breaking usage of 5.x
message object with other providers, its hardly 'swallowing expected delays'.
The message setter and getter can be trivially handled in 5.x (getting and
setting a basic long field), without the producer.setDeliveryDelay() method or
delivery delay feature being implemented in 5.x, i.e. the
producer.setDeliveryDelay() would still throw until actually implemented.
> I contend that the current UOE approach matches several project goals:
>
> 1. The implementation matches the description in the JIRA
>
> 2. The mailing list discussion has settled on this approach
>
I would say that the mailing list discussion has not addressed this
particular aspect, and it highly likely noone thought of it until I pointed it
out. As a breaking change I think it runs rather counter to the entire idea of
using the newer api jar being 'more compatible' as some seem to think.
> 3. The desire to keep PR changes concise
>
Fixing the message method issue would use less characters than throwing the
exceptions would so arguably it would be more concise.
Weve spent many many multiples of the time it would take to fix this, just
discussing. I'm done, break what you like.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 631180)
Time Spent: 7h (was: 6h 50m)
> Add JMS 2.0 support
> -------------------
>
> Key: AMQ-7309
> URL: https://issues.apache.org/jira/browse/AMQ-7309
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Broker, JMS client
> Reporter: Jean-Baptiste Onofré
> Assignee: Jean-Baptiste Onofré
> Priority: Major
> Fix For: 5.17.0
>
> Time Spent: 7h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
