You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Tellier Benoit (JIRA)" <se...@james.apache.org> on 2018/07/11 10:32:00 UTC
[jira] [Closed] (JAMES-2309) Long overflow in JMS delays
[ https://issues.apache.org/jira/browse/JAMES-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tellier Benoit closed JAMES-2309.
---------------------------------
> Long overflow in JMS delays
> ---------------------------
>
> Key: JAMES-2309
> URL: https://issues.apache.org/jira/browse/JAMES-2309
> Project: James Server
> Issue Type: Bug
> Components: Queue
> Reporter: Tellier Benoit
> Priority: Major
> Labels: bug
>
> When using a Long.MAX delay value:
> - TimeUnit delay conversion to ms detect the overflow and fallback to maximum value
> - But nextDeliverycalculation in *{color:#ffc66d}getJMSProperties{color}* adds that value to current time. And that computation DO overflow.
> See DelayedMailQueueTest :: *{color:#ffc66d}enqueueWithVeryLongDelayShouldDelayMail{color}*
> The consequence is that a delayed mail is directly delivered. Correct behaviour would be to keep preserving Long.MAX value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org