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/11 15:02:00 UTC

[jira] [Commented] (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=17472805#comment-17472805 ] 

Jean Helou commented on JAMES-3696:
-----------------------------------

The tests actually already account for the eventual consistency of the filter propagation, they include a call to `awaitRemove()` which is empty for most implementations and is defined as 
{code:java}
@Override
public void awaitRemove() {
    try {
        Thread.sleep(100);
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    }
} {code}
in PulsarMailqueueTest

 

What likely happens is that 100ms is too little for the CI plateform, there are 2 options:

- change all the assertions on remove to use awaitility
- increase the wait time (if possible only on CI, we could try to resolve the CI env variable and conditionnaly have a larger wait 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