Hi Benoit, Food for thought: https://github.com/apache/james-project/pull/3208
I did a quick review of it, and the fixes make sense to me (I asked the agent to do TDD: reproduce the reported issue first). I hope it helps. I will properly double check the fixes later. Quan On Fri, Sep 25, 2026 at 7:42 PM Benoit TELLIER via server-dev < [email protected]> wrote: > Hello Felix > > That's a classic Jooq / R2DBC issue: it badly support streaming as it hold > a live connection. > > The reindexing read live data as it needs it (so 2 message per second for > instance) and keep it opens as it iterates/ > > The listing query then times out after 10s, thus the symptoms. > > We encountered that in over parts of the PG implem and used buffering ( > intermediate .collectList ) to pull results in memory, and return the > driver thread as fast as we could. > > The tricky point is that EG Cassandra driver supports reading large result > sets without monopolizing driver resources. It thus don't need that memory > buffering. Any fix doing this would then need not to impact Cassandra > implementation that could be doing the optimal list-as-it-comes operation. > > Another solution is to rethink "streaming" and switch it to explicit > separated request per page size. This lift the time limit as we no longer > hold a collection at the cost of repeated queries. A sample can be found > here > https://github.com/apache/james-project/blob/bf100353ac3c4fc76d9ecced7472528b43e1ca21/mailbox/postgres/src/main/java/org/apache/james/mailbox/postgres/mail/dao/PostgresMailboxMessageDAO.java#L487 > > A generic adoption of this pattern can solve the problem you mention (at > the cost of snapshot isolation which I believe we do not really care. > I'll try to propose a little something 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 25, 2026 12:51 PM, from Felix Auringer <[email protected] > >Hello, > > For some time now, I have seen a timeout error in the postgres executor: > o.a.j.b.postgres.utils.PostgresExecutor - Time out executing Postgres > query. May need to check either jOOQ reactive issue or Postgres DB > performance. > This was mainly happening in TMail and was reported here: > github.com/linagora/tmail-backend/issues/1599 > > I have now found a way to reproduce this reliably with the Docker image > built from the current James master > (bf100353ac3c4fc76d9ecced7472528b43e1ca21). > When using opensearch as the search backend and triggering a full reindex > with curl -XPOST > 'http://<IP>:<port>/mailboxes?task=reIndex&messagesPerSecond=1', > I observe the following behavior: > > 2026-09-25T10:29:41.968Z [INFO ] o.a.j.webadmin.mdc.LoggingRequestFilter - > WebAdmin request received > 2026-09-25T10:29:41.974Z [INFO ] o.a.m.tools.indexer.ReIndexerPerformer - > Starting a full reindex > 2026-09-25T10:29:41.985Z [INFO ] o.a.j.webadmin.mdc.LoggingResponseFilter > - WebAdmin response received > 2026-09-25T10:29:43.178Z [INFO ] > o.a.j.m.o.e.OpenSearchListeningMessageSearchIndex - Indexing mailbox > email-88f7e4e1-cb74-47fb-a4f6-3046afc29714 of user re-indexing on message 1 > 2026-09-25T10:29:44.120Z [INFO ] > o.a.j.m.o.e.OpenSearchListeningMessageSearchIndex - Indexing mailbox > email-88f7e4e1-cb74-47fb-a4f6-3046afc29714 of user re-indexing on message 2 > 2026-09-25T10:29:45.125Z [INFO ] > o.a.j.m.o.e.OpenSearchListeningMessageSearchIndex - Indexing mailbox > email-88f7e4e1-cb74-47fb-a4f6-3046afc29714 of user re-indexing on message 3 > 2026-09-25T10:29:46.128Z [INFO ] > o.a.j.m.o.e.OpenSearchListeningMessageSearchIndex - Indexing mailbox > email-88f7e4e1-cb74-47fb-a4f6-3046afc29714 of user re-indexing on message 4 > 2026-09-25T10:29:47.131Z [INFO ] > o.a.j.m.o.e.OpenSearchListeningMessageSearchIndex - Indexing mailbox > email-88f7e4e1-cb74-47fb-a4f6-3046afc29714 of user re-indexing on message 5 > 2026-09-25T10:29:48.135Z [INFO ] > o.a.j.m.o.e.OpenSearchListeningMessageSearchIndex - Indexing mailbox > email-88f7e4e1-cb74-47fb-a4f6-3046afc29714 of user re-indexing on message 6 > 2026-09-25T10:29:49.137Z [INFO ] > o.a.j.m.o.e.OpenSearchListeningMessageSearchIndex - Indexing mailbox > email-88f7e4e1-cb74-47fb-a4f6-3046afc29714 of user re-indexing on message 7 > 2026-09-25T10:29:50.147Z [INFO ] > o.a.j.m.o.e.OpenSearchListeningMessageSearchIndex - Indexing mailbox > email-88f7e4e1-cb74-47fb-a4f6-3046afc29714 of user re-indexing on message 8 > 2026-09-25T10:29:51.143Z [INFO ] > o.a.j.m.o.e.OpenSearchListeningMessageSearchIndex - Indexing mailbox > email-88f7e4e1-cb74-47fb-a4f6-3046afc29714 of user re-indexing on message 9 > 2026-09-25T10:29:52.052Z [ERROR] o.a.j.b.postgres.utils.PostgresExecutor - > Time out executing Postgres query. May need to check either jOOQ reactive > issue or Postgres DB performance. > java.util.concurrent.TimeoutException: Did not observe any item or > terminal signal within 10000ms in 'flatMapMany' (and no fallback has been > configured) > at > reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.handleTimeout(FluxTimeout.java:296) > at > reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.doTimeout(FluxTimeout.java:281) > at > reactor.core.publisher.FluxTimeout$TimeoutTimeoutSubscriber.onNext(FluxTimeout.java:420) > at > reactor.core.publisher.FluxOnErrorReturn$ReturnSubscriber.onNext(FluxOnErrorReturn.java:162) > at > reactor.core.publisher.MonoDelay$MonoDelayRunnable.propagateDelay(MonoDelay.java:270) > at > reactor.core.publisher.MonoDelay$MonoDelayRunnable.run(MonoDelay.java:285) > at > reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:68) > at > reactor.core.scheduler.SchedulerTask.call(SchedulerTask.java:28) > at java.base/java.util.concurrent.FutureTask.run(Unknown Source) > at > java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown > Source) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.base/java.lang.Thread.run(Unknown Source) > 2026-09-25T10:29:52.058Z [INFO ] o.a.m.tools.indexer.ReIndexerPerformer - > Full reindex finished > 2026-09-25T10:29:52.059Z [ERROR] o.a.james.task.SerialTaskManagerWorker - > Task was partially performed. Check logs for more details. Taskid : > TaskId{value=9553e1df-9ad0-42d6-b90d-30c5882b8d17} > > This error always happens 10 seconds after starting the reindex task. > Therefore, exactly 9 batches of the size specified with messagesPerSecond > are processed. > When indexing 2 messages per second, the indexer manages to index the > first 18 messages, when indexing 5 messages per second, the first 45 > messages are indexed, and so on... > > I don't know much about this part of the codebase and would be happy about > help to debug this. > Did somebody else ever see this error or can somebody else reproduce it? > > Best regards, > Felix > --- > Gesellschaft für interkulturelles > Zusammenleben gGmbH (GIZ) > Felix Auringer > IT > Reformationsplatz 2 > 13597 Berlin > > Tel: 030/513 0100 00; Fax: 030/513 0100 09 > giz.berlin; [email protected] > > Amtsgericht Charlottenburg HRB 200872 B > Geschäftsführerin: Dr. Britta Marschke > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
