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 "Jean Helou (Jira)" <se...@james.apache.org> on 2022/01/14 12:46:00 UTC
[jira] [Comment Edited] (JAMES-3696) Solve instable test for the pulsar mail queue
[ https://issues.apache.org/jira/browse/JAMES-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476117#comment-17476117 ]
Jean Helou edited comment on JAMES-3696 at 1/14/22, 12:45 PM:
--------------------------------------------------------------
> This makes build profiles harder to grasp, issues harder to reproduce. Could also be seen as an entry barreer to people running the build for the first time on slow environments.
As long as we use a constant increase factor shared in all tests and applied to all static wait times, it shouldn't affect the build profile. On the other hand, don't you think the current build time of James is also a barrier to entry (IIRC a full build is somewhere around 2h30, I don't even try to run it anymore since it's so slow) ?
Static wait times mean slower tests *everywhere* , tests slower than they need to be on developpers machine means wasted human time :(
was (Author: jeantil):
> This makes build profiles harder to grasp, issues harder to reproduce. Could also be seen as an entry barreer to people running the build for the first time on slow environments.
As long as we use a constant increase factor it shouldn't affect the build profile much. On the other hand, don't you think the current build time of James is also a barrier to entry (IIRC a full build is somewhere around 2h30, I don't even try to run it anymore since it's so slow) ?
Static wait times mean slower tests *everywhere* , tests slower than they need to be on developpers machine means wasted human time :(
> Solve instable test for the pulsar mail queue
> ---------------------------------------------
>
> Key: JAMES-3696
> URL: https://issues.apache.org/jira/browse/JAMES-3696
> Project: James Server
> Issue Type: Sub-task
> Components: pulsar, Queue
> Affects Versions: master
> Reporter: Benoit Tellier
> Priority: Major
> Labels: bug
>
> https://ci-builds.apache.org/job/james/job/ApacheJames/job/PR-826/7/
> Pulsar mail queue bringed in some unstable tests
> {code:java}
> Test Result (4 failures / +4)
> org.apache.james.queue.pulsar.PulsarMailQueueTest.removeByRecipientShouldRemoveSpecificEmail
> org.apache.james.queue.pulsar.PulsarMailQueueTest.removeByRecipientShouldRemoveSpecificEmailWhenMultipleRecipients{List, MailAddress}[5]
> org.apache.james.queue.pulsar.PulsarMailQueueTest.removeByRecipientShouldRemoveSpecificEmailWhenMultipleRecipients{List, MailAddress}[6]
> org.apache.james.queue.pulsar.PulsarMailQueueTest.removeShouldRemoveMailFromStoreWhenFilteredOut
> {code}
> Looking at the first, some email expected to be deleted were not:
> {code:java}
> Error Message
> Expecting actual:
> ["name1", "name2"]
> to contain exactly (and in same order):
> ["name1"]
> but some elements were not expected:
> ["name2"]
> {code}
> Maybe because propagation of the delete filter is asynchronous? (IE the client delete returns when enqueuing the filter but without any warranty so as when it would be dequeued and applied). If so this isa design flaw and I hardly see how to improve that .
> Or we add a delay in the tests to relax the consistency guaranty?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org