james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <server-...@james.apache.org>
Subject [jira] [Commented] (JAMES-2309) Long overflow in JMS delays
Date Thu, 05 Jul 2018 12:29:00 GMT

    [ https://issues.apache.org/jira/browse/JAMES-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16533590#comment-16533590
] 

ASF GitHub Bot commented on JAMES-2309:
---------------------------------------

GitHub user nstdio opened a pull request:

    https://github.com/apache/james-project/pull/125

    JAMES-2309 Long overflow in JMS delays.

    When using a Long.MAX as delay value the computeNextDeliveryTimestamp throws
    ArithmeticException caused by long overflow. Now we log the warning message and
    falling back to the maximum long value.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/nstdio/james-project JAMES-2309

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/james-project/pull/125.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #125
    
----
commit a333168669db01031982bd9800e2b33c5aea81e8
Author: Edgar Asatryan <nstdio@...>
Date:   2018-07-05T12:25:45Z

    JAMES-2309 Long overflow in JMS delays.
    
    When using a Long.MAX as delay value the computeNextDeliveryTimestamp throws
    ArithmeticException caused by long overflow. Now we log the warning message and
    falling back to the maximum long value.

----


> 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


Mime
View raw message