You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@james.apache.org by GitBox <gi...@apache.org> on 2021/09/28 06:24:44 UTC

[GitHub] [james-project] chibenwa opened a new pull request #677: JAMES-3656 Ignore by default failures in non essential feature prior …

chibenwa opened a new pull request #677:
URL: https://github.com/apache/james-project/pull/677


   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). Apparently this is enough to create contention!
   
   
   ```
   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)
   ```
   
   This results in one email not making it to its destination...
   
   ```
   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.
   ```
   
   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 philosophy 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 mentioned test stable.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org


[GitHub] [james-project] chibenwa merged pull request #677: JAMES-3656 Ignore failures in non essential feature prior delivery

Posted by GitBox <gi...@apache.org>.
chibenwa merged pull request #677:
URL: https://github.com/apache/james-project/pull/677


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@james.apache.org
For additional commands, e-mail: notifications-help@james.apache.org