[
https://issues.apache.org/jira/browse/JAMES-3696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17476117#comment-17476117
]
Jean Helou commented on JAMES-3696:
-----------------------------------
> 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: [email protected]
For additional commands, e-mail: [email protected]
