Le 26/10/2015 11:08, Matthieu Baechler a écrit :
On 26/10/2015 10:54, Benoit Tellier wrote:
[...]
Seriously, I think dropping MESSAGE SEQUENCE NUMBER and returning an
error on distributed implementation is our simplest walk-around on this
topic... Doing overwise demands to add capabilities to the
MessageManager to handle MESSAGE SEQUENCE NUMBER with really tricky code.
The real problem is about deletion because addition can be managed by
the atomic row trick and immutable datamodel.
We completely agree.
I think we could create a Session row that map MESSAGE SEQUENCE NUMBER
to the real messages. Then, for a given session, we never remap things,
we only add messages to this row. In case of EXPUNGE, we create a new
row that won't be used until a new session is open.
Message Sequence Number are defined as mutable by the RFC. Having them
being immutable look like non RFC compliant to me.
I mean, the idea is nice, but client using MESSAGE SEQUENCE NUMBERS
won't be designed to work this way, I think.
https://tools.ietf.org/html/rfc3501#section-2.3.1.2
That way, a client can't use a MESSAGE SEQUENCE NUMBER wrongly because
it always maps to a given message.
With the model you suggest, I understand that a Session Row stops from
being used only when a clients is disconnected. It represents his view
of the correspondence on his mailbox selection moment. He use it until
he is disconnected.
Is this what you suggest ?
Do you get it ?
Hence, as it is immutable, he can not address added messages after this
selection using MESSAGE SEQUENCE NUMBERS as these changes will be
visible upon re-selection.
Look like a problem to me...
Also, you have data races unless you manage APPEND and EXPUNGE
operations in atomic way. This means MESSAGE SEQUENCE NUMBERS should be
included in the process. This means, to have a data race free
implementation, we need the mailbox manager to handle MESSAGE SEQUENCE
NUMBER consistency, and not the protocol part, that did it threw the
event system. Do we agree on this ?
--------------------
A friend (Erwan Guyomarc'h), who is working on James with me, suggested
an other solution. It has its problems, but I put it here as it is
interesting...
Suppose we have a at least one delivery distributed event system.
The idea is, instead of maintaining a double index between UID and
Message Sequence Number, we only store on each SelectedMailboxImpl an
uid set.
ADDED events is an insertion on this set
EXPUNGE events is a deletion on this set
Of course these operations are not CRDT.
The problem comes from ADDED operation being reordered after EXPUNGED
operations.
ADDEDD 7
EXPUNGED 7
is not equivalent to
EXPUNGED 7
ADDED 7
Now assume we have a causal order.
We also have the certitude to see only one ADDED event per UID.
If we reject EXPUNGE commands if the specified uid is absent from the
SelecteMailboxImpl uid set.
We might have concurrent problems, but with this we have an eventual
consistent MESSAGE SEQUENCE NUMBERS <=> UID correspondance across
servers. Of course with this solution the difficulty is to have causal
ordering. Which means vector clocks...
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
