[
https://issues.apache.org/jira/browse/AMQ-7309?focusedWorklogId=630581&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-630581
]
ASF GitHub Bot logged work on AMQ-7309:
---------------------------------------
Author: ASF GitHub Bot
Created on: 28/Jul/21 15:15
Start Date: 28/Jul/21 15:15
Worklog Time Spent: 10m
Work Description: gemmellr commented on pull request #682:
URL: https://github.com/apache/activemq/pull/682#issuecomment-888394147
@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.
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.
These methods exist precisely for this use case, for [foreign] providers to
set the needed values on message objects being sent [which arent their own
implementation].
> This method is for use by JMS providers only to set this field when a
message is sent. This message cannot be used by clients to configure the
delivery time of the message. This method is public to allow a JMS provider to
set this field when sending a message whose implementation is not its own.
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.
--
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: 630581)
Time Spent: 5h (was: 4h 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: 5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
