Lessons learned from a painful production deployment

[Benoit TELLIER <bt...@apache.org>]

Hi all,

We did do on last week a very complicated production deployment for one 
of Linagora customers.

Their load is very special: many very big messages which put an undue 
pressure on James. Combined with a live data ingestion from an older 
platform.

There are numerous lessons learned, which will lead to code evolutions.

The changes includes:
   - memory footprint optimization and file buffering in more places
   - Limit the numbers of items in EMail/get
   - Infinite loops with forwards
   - Some handy performance related degraded mode options for emergency 
situations like "do not index bodies in OpenSearch"
   - Couple other performance enhancements.

A big topic that remains to be handled in the IMAP stack is handling 
slow receivers (https://issues.apache.org/jira/browse/JAMES-3997).
I strongly suspect it is still affecting us. I would need to propose a 
code patch applying this for IMAP FETCH.

I asked the Linagora team to help me through this. They did already 
start to open issues / polish the pull requests I did open.

While Linagora needs those code evolutions, it would seem very fine to 
me to add toogle to disable some of those changes if the community is 
not enthousiast on some of those. We could do that retrospectively if 
needed.

Best regards,

Benoit TELLIER



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