Benoit Tellier created JAMES-3656:
-------------------------------------

             Summary: 
WithCassandraPassThroughBlobStoreMutableTest::oneHundredMailsShouldBeWellReceived
 is unstable
                 Key: JAMES-3656
                 URL: https://issues.apache.org/jira/browse/JAMES-3656
             Project: James Server
          Issue Type: Bug
          Components: JMAP
    Affects Versions: 3.7.0
            Reporter: Benoit Tellier
            Assignee: Antoine Duprat


https://ci-builds.apache.org/job/james/job/ApacheJames/job/master/281/testReport/junit/org.apache.james/WithCassandraPassThroughBlobStoreMutableTest/oneHundredMailsShouldBeWellReceived_GuiceJamesServer_/

This master build did fail because JMAP filtering failed for one of the emails.

This test sends 100 emails to a single recipient. Single recipients have their 
filters on a single Primary Key, and filters are managed by a Cassandra 
Lightweight transaction (refer to JAMES-3435 for background regarding 
LightWeight transactions in the project). Apparrently this is enough to create 
contention!


{code:java}
05:02:05.113 [ERROR] o.a.j.m.i.ProcessorImpl - Exception calling 
org.apache.james.jmap.mailet.filter.JMAPFiltering: Cassandra timeout during 
read query at consistency SERIAL (1 responses were required but only 0 replica 
responded)
com.datastax.driver.core.exceptions.ReadTimeoutException: Cassandra timeout 
during read query at consistency SERIAL (1 responses were required but only 0 
replica responded)
        at 
com.datastax.driver.core.exceptions.ReadTimeoutException.copy(ReadTimeoutException.java:124)
{code}

This results in one email not making it to its destination...

{code:java}
org.awaitility.core.ConditionTimeoutException: 
Assertion condition defined as a lambda expression in 
org.apache.james.utils.TestIMAPClient 
expected: 100L
but was : 99L within 10 seconds.
{code}

There is little things we can do regarding LWT performance (since Cassandra 
3.11.10 even SERIAL reads implies to commit an empty update!).

However, as 'filtering' is (in my opinion at least) not critical - my 
phylosophy would be "don't loose emails - even if that means some features 
could not be run...".

As such I propose to ignore errors arising upon JMAPFiltering - this would also 
make the above mentionned test stable.




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to