Benoit Tellier created JAMES-3728:
-------------------------------------
Summary: ElaticSearch race condition between email moves and flag
changes
Key: JAMES-3728
URL: https://issues.apache.org/jira/browse/JAMES-3728
Project: James Server
Issue Type: Improvement
Components: elasticsearch, mailbox
Affects Versions: 3.7.0
Reporter: Benoit Tellier
h3. Description
We are writting a JMAP client app called TMail written in FLutter.
In the sent mailbox we noticed the following behaviour:
{code:java}
Request
{
"using": [
"urn:ietf:params:jmap:core",
"urn:ietf:params:jmap:mail"
],
"methodCalls": [
[
"Email/query",
{
"accountId": "{{accountId}}",
"limit": 20,
"filter": {
"inMailbox": "{{Sent}}",
"notKeyword": "$seen"
},
"sort": [{
"property":"sentAt",
"isAscending": false
}],
"position": 0
},
"c2"
],
[
"Email/get",
{
"accountId": "{{accountId}}",
"properties": [
"subject",
"from",
"receivedAt",
"sentAt",
"preview",
"hasAttachment",
"mailboxIds",
"keywords"
],
"#ids": {
"resultOf": "c2",
"name": "Email/query",
"path": "ids/*"
}
},
"c3"
]
]
}
Response
{
"sessionState": "2c9f1b12-b35a-43e6-9af2-0106fb53a943",
"methodResponses": [
[
"Email/query",
{
"accountId":
"3ce33c876a726662c627746eb9537a1d13c2338193ef27bd051a3ce5c0fe5b12",
"queryState": "11dc2cfd",
"canCalculateChanges": false,
"ids": [
"c331d3c0-90ac-11ec-984e-e3f8b83572b4",
"36128e70-32e8-11ec-a759-2fef1ee78d9e",
"4b0db860-32e6-11ec-a759-2fef1ee78d9e",
"4f769140-2cc6-11ec-a759-2fef1ee78d9e",
"3b21cb60-2cc6-11ec-a759-2fef1ee78d9e",
"254999d0-2cc6-11ec-a759-2fef1ee78d9e",
"19707570-2cc6-11ec-a759-2fef1ee78d9e",
"0e877d70-2cc6-11ec-a759-2fef1ee78d9e",
"8b5a5280-2cc3-11ec-a759-2fef1ee78d9e",
"826ba3e0-2cc3-11ec-a759-2fef1ee78d9e",
"5f771f90-2cc3-11ec-a759-2fef1ee78d9e"
],
"position": 0
},
"c2"
],
[
"Email/get",
{
"accountId":
"3ce33c876a726662c627746eb9537a1d13c2338193ef27bd051a3ce5c0fe5b12",
"notFound": [],
"state": "c55b33d0-a52e-11ec-90ba-e169393c493e",
"list": [
{
"preview": "------- Forwarded message ------- Subject:
[linshare-mobile-flutter-app-android-release] - Build [success] Date: October
8, 2021 12:50 PM From: [email protected] To: [email protected]
<[email protected]>, [email protected] <[email protected]",
"hasAttachment": false,
"keywords": {
"$seen": true
},
"subject": "Fwd:
[linshare-mobile-flutter-app-android-release] - Build [success]",
"mailboxIds": {
"abb99c10-18d9-11eb-a677-2990b970028d": true
},
"from": [
{
"name": "Lê Nguyễn User B",
"email": "[email protected]"
}
],
"sentAt": "2021-10-14T07:51:15Z",
"id": "826ba3e0-2cc3-11ec-a759-2fef1ee78d9e",
"receivedAt": "2021-10-14T07:51:15Z"
},
....
{code}
As we can see, `Email/query` and `Email/get` disagrees on wether the message is
seen or not!
This happens primarily in the Sent mailbox.
h3. Explanation ?
Email/query relies on elasticSearch while Email/get relies on cassandra.
Getting those two in sync can be an issue and you can have inconsistencies
across the 2 data-stores. Now the indexing is done asynchronously which means
that if two actions happens veeeery quickly (say read then move emails or vice
versa) we can get into a data race in elasticsearch where we do the operation
in the wrong order which could result into what you actually see.
Moving emails to sent box does just that: mark as seen and move in one request
To be very techish our event system don't guaranty ordering, and the underlying
operation don't commute.
Ordering don't seem achievable on RabbitMQ (contrary to Pulsar/Kafka)
Working on commutativity can likely help!
h3. Fix?
I got an idea of a fix. Basically the key problem is that we use a mutable id
as an indexing key which results in poor, non transactional behaviour if
indexing requests get reordered. Of course it demands significant redesign of
ES layers... And might bring additional concerns!
h3. Original report from Dat Pham Hoang
https://github.com/linagora/tmail-flutter/issues/340#issuecomment-1069188877
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
