On Sun, 2020-12-06 at 22:33 +0100, Jean Helou wrote: > Hello, > > I'm currently trying to increase overall efficiency of the > Distributed > > James server. > > > > I have some concerns but i feel imposterish for posting them as they > most > likely come from my own lack of knowledge, i'll still try just in > case some > of points are valid :) > > - `users` we rely on LWT for throwing "AlreadyExist" exceptions. LWT > > are likely unnecessary as the webadmin > > presentation layer is offering an idempotent API (and silents the > > AlreadyExist exceptions). Only the CLI > > (soon to be deprecated for Guice products) makes this distinction. > > > So from a user perspective adding a user would always succeed. But > would it > succeed by doing nothing (the current behaviour in silencing the > AlreadyExist exception) or would it succeed by effectively > overwriting the > user (in a last write wins manner) ? This is a completely different > behaviour which is not necessarily desirable. > this can be further divided into 2 different cases : > - there are concurrent attempts to create the same user (in which > case the > user data is very likely the same or very close, and has possibly > never > been exposed to a human) in which case the LWW behaviour may be > acceptable > - A user has existed for a long time (definition of long to be > defined but > I would say above a few seconds :) ) in which cas overwriting is most > likely not acceptable >
Fully agree: being idempotent for a command is not the same thing as "having unpredicable things happening without complaining". I almost never want to overwrite a user without explicitely asking for it: as a user creating a resource is not the same intention as modifying it. > > > - `domains` we rely on LWT for throwing "AlreadyExist" exceptions. > > LWT > > are likely unnecessary as the webadmin > > presentation layer is offering an idempotent API (and silents the > > AlreadyExist exceptions). Only the CLI > > (soon to be deprecated for Guice products) makes this distinction. > > Discussions have started on the topic and a proof of > > concept is available. > > > > same as above > > Why it would be ok to drop LWT for ACL updates only to replace it by > eventsourcing when you write: > > LWT are required for `eventSourcing`. As event sourcing usage is > > limited > to low-usage use cases, the performance degradations are not an > issue. > Doesn't that mean that ACLs would still rely on LWT but within an > additional layer ? Yes, it's the proposed solution AFAIU. > Also for ACLs isn't eventual consistency acceptable ? using > transactions to > avoid non serial writes but accepting stale reads ? I would say ACL could take effect in an eventual consistency way. > That's the limit of my understanding : all the flags/UID/IMAP > concerns are > beyond my current knowledge but I'll enjoy reading the comments :) Cheers, -- Matthieu Baechler --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
