[
https://issues.apache.org/jira/browse/JAMES-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16539863#comment-16539863
]
ASF GitHub Bot commented on JAMES-2309:
---------------------------------------
Github user chibenwa commented on the issue:
https://github.com/apache/james-project/pull/125
Hi,
This pull request has just been merged.
One very last thing: I don't have write access to this repository, hence I
can not close this issue. Wouldn't you mind doing it for me? It would avoid me
annoying the Apache INFRA team with such simple concerns.
Thanks again,
Cheers,
Benoit
> 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: [email protected]
For additional commands, e-mail: [email protected]
