When using a Long.MAX delay value:
- TimeUnit delay conversion to ms detect the overflow and fallback to maximum value
- But nextDeliverycalculation in getJMSProperties adds that value to current time. And that computation DO overflow.
See DelayedMailQueueTest :: enqueueWithVeryLongDelayShouldDelayMail
The consequence is that a delayed mail is directly delivered. Correct behaviour would be to keep preserving Long.MAX value.