Hi James Support Team, We are running Apache James with S3 blob storage and are seeing occasional S3connectivity timeout issues. It appears each attempt waits about 10 seconds, andretries continue until the S3 connection succeeds, which can result in requeststaking a long time to complete while the pod remains available to serve traffic. We have a few questions: 1. What timeout and retry settings do you recommend for production environments using S3? 2. Does Apache James have a recommended approach for: * Liveness checks * Readiness checks * Dependency health checks (such as S3) 3. During temporary S3 connectivity issues, is it better to: * Keep the pod serving traffic and fail requests quickly, or * Mark the pod as unready until S3 is available again? 4. Are there any recommended patterns (circuit breaker, degraded mode, fast-fail configuration, etc.) to prevent long S3 waits from causing user-facing timeouts? 5. Can periodic S3 health checks be disabled or configured differently? 6. We noticed the S3 health-check timeout is set to 10 seconds and appears to be hardcoded in the code. Is there a way to configure a lower timeout value, or is code customization required? 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 Our goal is to reduce the impact of temporary S3 issues and avoid long requestdelays. Thanks for your help. Best regards, James A
