DNS, MX, PTR (reverse dns) also aliases for users, mb existense, password, hashes, sieve rules other stuff which asked alot of times you dont want to always going to database. Eith ttl for example 15 mins i think good.
чт, 24 сент. 2026 г., 20:46 Benoit TELLIER via server-user < [email protected]>: > caffeine is a nice inmemory cache > > We can indeed leverage it for single machine deployment (and have same > listener based invalidation strategy) > > Sure it is better perfs... As long as one do not need serveral machines > (load distribution, reliability) > > If we take some of the deployments operated by Linagora it involves 10 > James servers operated in round robin fashion. A Cafeine local cache means > low hit rate and duplicated memory storage costs (1 per James potentially) > which makes it impractical except for things like "domains". > > What do we need in James? Potentially both. > > I would also say that we do not need to cache the full mailbox things like > messages do not deserve to be in a cache IMO. > > -- > > > Best regards, > > Benoit TELLIER > > General manager of Linagora VIETNAM. > Product owner for Twake-Mail product. > Chairman of the Apache James project. > > Mail: [email protected] > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > > > On Sep 24, 2026 3:27 PM, from Ilya Terskov <[email protected]>Oh well > then because of license surely better use valkey. Also i see > here Caffeine which apache 2.0 and already part of it used in java > ecosystem so for standalone single server it mb even better? In memory and > persistent best of both worlds? > > чт, 24 сент. 2026 г., 19:33 Benoit TELLIER via server-user < > [email protected]>: > > > KVRock vs Redis > > > > Same API > > Different performance profile > > > > TLDR Kvrocks offers disk key value store compatible with redis API > > We qualified it and it shines eg for RSpamd per user bayesian database > > It is not fit as a generic purpose cache: for this we have PG / Cassandra > > > > Redis == Valkey we can update James to reflect this community shift. It's > > a drop in replacement, and I use the 2 interchangably. > > > > And all users can choose what they plug behind "Redis". > > > > -- > > > > > > Best regards, > > > > Benoit TELLIER > > > > General manager of Linagora VIETNAM. > > Product owner for Twake-Mail product. > > Chairman of the Apache James project. > > > > Mail: [email protected] > > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > > > > > > > On Sep 24, 2026 1:13 PM, from Ilya Terskov <[email protected]>About > > redis, there Apache Kvrocks dont it? It have redis protocol > > compability of i know right. Why redis and not Valkey or Kvrocks? > > Embeddeding Kvrocks seems cool and fast. > > > > чт, 24 сент. 2026 г., 18:03 Benoit TELLIER via server-user < > > [email protected]>: > > > > > > Sorry about this lots of PR dear Benoit :) > > > > > > No big deal ! > > > > > > > I just really think about where to migrate, stalwart have some > > > problems,postfix+dovecot... > > > > > > I would be happy to here more about that. > > > > > > And we will indeed together bring James + PG to the level you want it. > > > > > > There's a real role to take to make James + PG easy enough for self > > > hosters to use it. If you wish to contribute in that direction it would > > be > > > really appreciated. > > > > > > > So i want find all critical edge cases that can lead to data > corruption > > > BEFORE moving on James. > > > This kind of review is indeed really welcome! > > > > > > > So please dont be mad at me guys who reviews all this. > > > > > > I'm not mad. I'm sorry to be the guys that says "no". I understand > > > newcomers can't get why some decisions were made, and it's my role to > > > explain. I would consider the process we currently undergo as extremely > > > healthy.> The more feedback i got the more i populate my I database to > > make > > > more correct and dry PRs. > > > > > > +1 also if something surprises you don't hesitate to ask i=on the > mailing > > > list. > > > > > > We probably want to switch techie discussions related to contributions > to > > > [email protected] > > > > > > > warming > > > > > > well JVM does an incredible job on prod. For us it is a non-topic... > > > > > > > caching > > > > > > I have indeed concerns about repeated reads on mailbox, acl mostly. > > > > > > I have in mind a Redis based cache populated on read with configurable > > > expiration with mailbox listener built in invalidation as a design > > > (critical to achieve most of the time instant propagation of the > changes > > to > > > the cache). One day mailbox/redis maybe ! > > > > > > Slightly more complex than in memory caching > > > But distributes and scale (redis cluster). That's undocumented and on > the > > > back of my head but I would be happy to sheperd something going in that > > > direction.-- > > > > > > > > > Best regards, > > > > > > Benoit TELLIER > > > > > > General manager of Linagora VIETNAM. > > > Product owner for Twake-Mail product. > > > Chairman of the Apache James project. > > > > > > Mail: [email protected] > > > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > > > > > > > > > > > On Sep 24, 2026 12:17 PM, from Ilya Terskov <[email protected] > >Sorry > > > about this lots of PR dear Benoit :) > > > I just really think about where to migrate, stalwart have some > problems, > > > postfix+dovecot... Lets say i cant live with that low flexibility. So i > > > want find all critical edge cases that can lead to data corruption > BEFORE > > > moving on James. > > > > > > So please dont be mad at me guys who reviews all this. The more > feedback > > i > > > got the more i populate my I database to make more correct and dry PRs. > > > > > > After all critical things i move to optimise - warming, caching etc. > > > > > >
