[
https://issues.apache.org/jira/browse/JAMES-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16534570#comment-16534570
]
ASF GitHub Bot commented on JAMES-2309:
---------------------------------------
Github user chibenwa commented on a diff in the pull request:
https://github.com/apache/james-project/pull/125#discussion_r200583063
--- Diff:
server/queue/queue-jms/src/main/java/org/apache/james/queue/jms/JMSMailQueue.java
---
@@ -249,10 +249,17 @@ public void enQueue(Mail mail, long delay, TimeUnit
unit) throws MailQueueExcept
public long computeNextDeliveryTimestamp(long delay, TimeUnit unit) {
if (delay > 0) {
- return ZonedDateTime.now()
- .plus(delay, Temporals.chronoUnit(unit))
- .toInstant()
- .toEpochMilli();
+ try {
+ return ZonedDateTime.now()
+ .plus(delay, Temporals.chronoUnit(unit))
+ .toInstant()
+ .toEpochMilli();
+ } catch (ArithmeticException e) {
+ LOGGER.warn("The {} was caused by conversation {}({})
followed by addition to current timestamp. Falling back to Long.MAX_VALUE.",
+ e.getMessage(), delay, unit.name());
--- End diff --
Generally, when logging an exception, we also log it's stacktrace. That way
we are able to directly jump to the incriminated code section.
I'd propose:
```
LOGGER.warn("Exception encountered while computed JMS next delivery (delay
{} {})", delay, unit.name(), e);
```
> 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]
