[
https://issues.apache.org/jira/browse/NIFI-7639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre Villard resolved NIFI-7639.
----------------------------------
Resolution: Feedback Received
Apache NiFi 1.x is no longer maintained and no new release is planned on the
1.x release line. Marking as resolved as part of a cleanup operation. Please
open a new one with an updated description if this is still relevant for NiFi
2.x.
> JMSPublisher incorrectly uses JMS_Expiration and causes NumberFormatExpection
> -----------------------------------------------------------------------------
>
> Key: NIFI-7639
> URL: https://issues.apache.org/jira/browse/NIFI-7639
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Affects Versions: 1.11.4
> Reporter: Darren Hitchman
> Assignee: Darren Hitchman
> Priority: Major
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> {color:#000080}JMSPublisher incorrectly sets the{color}{color:#000080}
> TimeToLive when it should set the expiry of the message.{color}
> {color:#000080}This becomes an issue when using ConsumeJMS as it sets the
> jms_expiry to the expected value (ms timestamp) despite PublishJMS not being
> compatible (expecting ms duration for ttl). {color}
> {color:#000080}JMS expiry is defined as the timestamp (ms) when the messages
> expires where as the setTimeToLive defined in the jmsTemplate is referring to
> the number of ms from current time until expiry,{color}
> {color:#000080}else if
> {color}(entry.getKey().equals(JmsHeaders.{color:#660e7a}EXPIRATION{color})) {
>
> {color:#000080}this{color}.{color:#660e7a}jmsTemplate{color}.setTimeToLive(Integer.parseInt(entry.getValue()));
>
> {color:#000080}this{color}.{color:#660e7a}jmsTemplate{color}.setExplicitQosEnabled({color:#000080}true{color});
> }
> *Integer.parseInt fails to parse the Long that is defined in the attributes
> jms_expiration.
> A workout for this bug would be to use UpdateAttributes to change the
> jms_expiration value from a timestamp to a duration value e.g.
> ttl=jms_expiration-now() how ever PublishJMS should correctly honor the
> intended value.
> If we wish to continue using the spring framework for the TTL then a possible
> fix would be
> {color:#000080}this{color}.{color:#660e7a}jmsTemplate{color}.setTimeToLive(
> System.currentTimeMillis() - Long.parseLong(entry.getValue()));
>
> however I think we need to not break logic based on existing presumptions by
> users. We can for values less then 214748364.7 seconds (about 7 years) as
> per
> [https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q032030_.htm]
> . Any values less than this is presumed to be TTL rather than expiry
>
> more info here.
> http://activemq.apache.org/components/artemis/documentation/1.0.0/message-expiry.html
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
