Thank you for the feedback.
We understand that the log suggests a connection establishment issue between
Apache James and Amazon S3, which may point to an infrastructure or
network-related problem rather than a James software defect.
We have a few additional questions:
- Are there any Apache James, AWS SDK, Netty, or S3 client configuration
settings that could help improve resiliency against these intermittent
connection failures?
- Has anyone experienced similar intermittent S3 connection timeouts when
using Apache James with S3-backed blob storage?
- If so, what was the root cause, and what solution or mitigation helped
resolve the issue?
- Are there any recommended timeout, connection pool, retry, or DNS-related
settings that should be reviewed in a production environment running on
Kubernetes/EKS?
For additional context:
- Apache James 3.9.0
- Cassandra 4.1.10
- Amazon MQ (RabbitMQ)
- Amazon S3 Object Storage
- AWS EKS deployment
- Same AWS region for both James and S3
- Approximately 10 occurrences per day
- During the event, requests to James that require message content retrieval
can time out until connectivity recovers
Any guidance or shared experiences would be greatly appreciated.
On Tuesday, October 20, 2026 at 09:00:19 PM CDT, James A
<[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)
