[
https://issues.apache.org/jira/browse/AMQ-7309?focusedWorklogId=630664&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-630664
]
ASF GitHub Bot logged work on AMQ-7309:
---------------------------------------
Author: ASF GitHub Bot
Created on: 28/Jul/21 17:25
Start Date: 28/Jul/21 17:25
Worklog Time Spent: 10m
Work Description: gemmellr edited a comment on pull request #682:
URL: https://github.com/apache/activemq/pull/682#issuecomment-888484005
>
> Am I getting this right:
>
> 1. App currently uses JMS 2.0 API
>
> 2. App DeliveryDelay is required, and sets DeliveryDelay on all
messages through the JMS 2.0 MessageProducer
>
> 3. App has a way to handle that ActiveMQ (or other JMS 1.1) doesn't
have this method so it doesn't fail
>
> 4. Upon upgrade of activemq-client jar, this same unchanged code will
now throw an exception
>
No. App can use JMS 1.1 or JMS 2.0 API (EDIT: actually yes, the issue will
only arise if they use 2.0 to be fair...which would be more likely given its
the aim of this change). Configuring DeliveryDelay at all is not required. App
sends JMS 1.1 providers message object, through JMS 2.0 client (which tolerates
1.1 messages). After this change as-is, making the '1.1 provider' use the 2.0
API and throw UOE for impl, that will fail all the time during send.
Its possible for a JMS 2.0 client to work upon and send 1.1 message objects,
tolerating that the message.setDeliveryTime() method is defined but is not
being implemented by the older object (as clearly it didnt exist before, and so
couldnt be implemented, but backwards compatibility is the name of the game for
JMS). The JMS reference impl definitely did this.
Its possible for a JMS 2.0 client to tolerate being used only with the 1.1
API jar and for the message.setDeliveryTime() method to not actually be defined
at all at runtime. I dont recall if the RI did this.
Qpid JMS for example does both of these things. It will let you send a 1.1
message through it, and it will operate using the 1.1 API jar. It simply made
sense to support when transitioning specs, not dropping support for using it
with existing 1.1 providers (e.g 5.x) or existing applications, when they
couldn't actually be doing anything that wasnt still supported as all that API
all remained precisely for compatibility. Those are very different situations
from the method being defined, implemented and explicitly throwing UOE, and I
dont expect anything to really handle that it really makes no sense for it to
ever do so, especially for a long setter that is simply for recording 'what
actually happened during send'.
Note that all sends will fail, regardless whether a delivery delay is
configured on the producer, as a value is always being set on the sent messages
to either indicate the actual delivery time or ensure it records there was no
delay (as the sent message object may previously have had a deliveryTime value,
so that needs cleared to ensure the getter reflects reality).
>
> I don't see how #4 happens with #3 is in place as you indicated. I see a
chicken-and-the-egg problem.
>
> As as side-effect, by swallowing the 'set' and returning '0' on get, we'd
be silently wiping out the DeliveryDelay and users would have no indication as
to why DeliveryDelay is not occurring. It is just as reasonable to argue this
should error out so it is caught in unit/integration tests before they roll to
prod.
>
There is no delay unless the feature is implemented (which would remove any
need for a discussion), so there cant really be a sillent wiping. The message
setters dont control the delay as already discussed, and why would anyone
expect the message to be reporting a non-zero delivery time after send, when
producer.setDeliveryDelay(..) is throwing to indicate a delay cant actually be
configured?
--
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: 630664)
Time Spent: 5h 40m (was: 5.5h)
> 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: 5h 40m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
