[
https://issues.apache.org/jira/browse/AMQ-7309?focusedWorklogId=630638&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-630638
]
ASF GitHub Bot logged work on AMQ-7309:
---------------------------------------
Author: ASF GitHub Bot
Created on: 28/Jul/21 16:33
Start Date: 28/Jul/21 16:33
Worklog Time Spent: 10m
Work Description: mattrpav commented on pull request #682:
URL: https://github.com/apache/activemq/pull/682#issuecomment-888451870
@gemmellr replies inline..
> @mattrpav I'm not actually all that new to JMS at this stage really, I'm
at least a little aware what the methods are for and how the functionality is
used, having implemented JMS [2] in full including a full protocol mapping of
the functionality in a client capable of doing such scheduled delivery against
ActiveMQ 5 for several years now already. I have no idea why you think I was
talking about application or 'wrapper' usage of the setter, I wasn't.
Cool
> I think I was pretty clear about taking a 5.x message object and sending
it through another JMS 2 client, which is where the issue arises, as it
necessarily tries to call setJMSDeliveryTime on every message sent (as either
there is a delay, and the actual time needs set, or there isnt and it should be
clearing the potentially-non-zero existing value to indicate so). Such a client
client may have reasonably handled a JMS 1.1 object not having the method
implemented, as e.g. 5.x didnt so far, but it is not going to expect the method
to be actually implemented but throw UOE.
Yeah, I'm trying to piece your scenario together, but coming up short.
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
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.
> If 5.x is going to use the JMS 2 API then any JMS 2 message object sent
with it should reasonably be expected to come back with a delivery time value
of 0 after send if there is no delay occurring, i.e it should be doing the
equivalent of setJMSDeliveryTime(0) by itself on its own messages, and actually
calling setJMSDeliveryTime(0) on other providers messages to clear any existing
non-zero value.
I think it is an interesting suggestion-- there is a JIRA open for the
DeliveryDelay impl here: https://issues.apache.org/jira/browse/AMQ-8320
--
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: 630638)
Time Spent: 5h 10m (was: 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 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
