Thank you for your feedback. We are running Apache James with S3 blob storage and have observed intermittent S3 health-check/connectivity timeout failures. Our current configuration appears to wait 10 seconds per attempt with a maximum of 3 retries, resulting in requests blocking for up to ~30 seconds while the pod continues serving traffic.
1) What values are recommended for production-scale deployments for Apache James or AWS SDK configuration properties that control S3 timeout and retry behavior? 2) Does Apache James have a recommended pattern for distinguishing liveness vs readiness vs and dependency health (S3), or is dependency degradation expected to influence readiness/liveness status? 3) For temporary S3 connectivity issues, is the recommended approach to keep the James pod serving traffic and fail requests fast, or to make the pod unready and remove it from service? 4) Are there existing James capabilities or community-recommended patterns (circuit breaker, degraded mode, dependency health indicators, fast-fail configuration) to prevent long S3 waits from consuming request threads and causing user-facing timeout? Any production deployment recommendations or examples would be greatly appreciated. Best Regards, James A. On 2026/10/21 02:30:56 Benoit TELLIER via server-user wrote: > Hello James A > > 2026-10-19 16:06:22 DEBUG [aws-java-sdk-NettyEventLoop-0-63] > s.a.a.h.n.n.i.NettyRequestExecutor - Failed to create connection to > https://s3.us-east-1.amazonaws.com/ > > It appears the Amazon S3 driver here do not succeed to open a connection to > James. I do not think it is a software problem but more of an > infrastructure/network problem... > > -- > > Best regards, > > Benoit TELLIER > > General manager of Linagora VIETNAM <https://linagora.vn>. > Product owner for Twake-Mail <https://github.com/linagora/tmail-flutter> > product. > Chairman of the Apache James project <https://james.apache.org/>. > > Mail: [email protected] > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > On Oct 21, 2026 at 4:01 AM, James A via server-user <[email protected]> > wrote: > > > Hi James Support Team, > > We are building an email platform using Apache James 3.9.0 with Cassandra > > 4.1.10, Amazon MQ (RabbitMQ), and Amazon S3 as the object store. > > > > Apache James is deployed as a containerized application on AWS EKS, using > > JMAP protocol to communicate with James. > > > > We are experiencing intermittent S3-related failures when retrieving email > > message summaries from James. On average, we observe approximately 10 > > occurrences per day, and during these periods, requests reaching James time > > out until the issue clears. > > > > As part of our investigation, we have reviewed the health and resource > > utilization of James, Cassandra, and S3, and all metrics appear to be > > within normal operating limits. Both the James application and the S3 > > buckets are deployed in the same AWS region, so cross-region latency is not > > a factor. > > > > Has anyone encountered a similar issue with Apache James and S3-backed blob > > storage? Any insights, recommendations, or known fixes would be greatly > > appreciated. > > > > The error stack trace is included below for reference. > > > > 2026-10-19 16:06:21 ERROR [parallel-6] o.a.james.PeriodicalHealthChecks - > > UNHEALTHY: ObjectStorage : Error checking ObjectSotrage > > > > java.util.concurrent.TimeoutException: Did not observe any item or terminal > > signal within 10000ms in 'handle' (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(FutureTask.java:317) > > at > > java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) > > at > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) > > at > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) > > at java.base/java.lang.Thread.run(Thread.java:1583) > > 2026-10-19 16:06:22 DEBUG [sdk-ScheduledExecutor-2-3] > > software.amazon.awssdk.request - Sending Request: > > DefaultSdkHttpFullRequest(httpMethod=GET, protocol=https, > > host=s3.us-east-1.amazonaws.com, encodedPath=/, > > headers=[amz-sdk-invocation-id, User-Agent], queryParameters=[]) > > 2026-10-19 16:06:22 DEBUG [sdk-ScheduledExecutor-2-3] > > s.a.a.c.i.h.p.s.AsyncSigningStage - Using SelectedAuthScheme: aws.auth#sigv4 > > 2026-10-19 16:06:22 DEBUG [aws-java-sdk-NettyEventLoop-0-63] > > s.a.a.h.n.n.i.NettyRequestExecutor - Failed to create connection to > > https://s3.us-east-1.amazonaws.com/ > > java.util.concurrent.CancellationException: null > > at > > java.base/java.util.concurrent.CompletableFuture.cancel(CompletableFuture.java:2510) > > at > > reactor.core.publisher.MonoCompletionStage$MonoCompletionStageSubscription.cancel(MonoCompletionStage.java:156) > > at > > reactor.core.publisher.FluxFlattenIterable$FlattenIterableSubscriber.cancel(FluxFlattenIterable.java:312) > > at > > reactor.core.publisher.FluxMapFuseable$MapFuseableConditionalSubscriber.cancel(FluxMapFuseable.java:365) > > at > > reactor.core.publisher.FluxHandleFuseable$HandleFuseableSubscriber.cancel(FluxHandleFuseable.java:265) > > at > > reactor.core.publisher.Operators$MultiSubscriptionSubscriber.drainLoop(Operators.java:2424) > > at > > reactor.core.publisher.Operators$MultiSubscriptionSubscriber.drain(Operators.java:2392) > > at > > reactor.core.publisher.Operators$MultiSubscriptionSubscriber.cancel(Operators.java:2204) > > at > > reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.handleTimeout(FluxTimeout.java:295) > > 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(FutureTask.java:317) > > at > > java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) > > at > > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) > > at > > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) > > at java.base/java.lang.Thread.run(Thread.java:1583) --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
